요약4일차는 컨테이너가 쓴 파일을 호스트가 실행하는 사건을 자동 회귀 테스트로 만들었다. 러너에 호스트 스텝(host.sh)을 넣고 시나리오 s01, s02를 추가했다. 그 과정에서 러너 테스트가 시나리오 추가에 흔들리는 구조를 찾아 격리했고, 3주차 계획을 위해 경로 비교 탐지기의 시작 조건(결정 9번)을 정했다. 결과는 사용자 VM 출력으로 확인한 것이고, 추정은 따로 표시했다. 질문결과확인 방법호스트가 컨테이너가 쓴 파일을 실행하는 사건을 러너가 재현할 수 있나가능. agent-run이 끝난 뒤 러너가 host.sh를 실행한다 (A안)실제 환경 s01s01, s02가 의도대로 판정하나s01은 BLOCK 한 번과 would_kill 한 번, s02는 SUSPECT만 있고 BLOCK 없음sudo ./r..

요약3일차는 TAG_HIT 을 보고 BLOCK 이나 SUSPECT 를 내리는 탐지기 write_exec_boundary 를 만들고, 실제 로더에서 호스트 실행이 BLOCK 으로 기록되는 것까지 확인했다. 확인 도중 인터프리터를 거친 실행(sh )은 탐지되지 않는다는 한계를 찾아 기록했다. 아래 결과는 사용자 VM 출력으로 확인한 것이고, 추정은 따로 표시했다. 질문결과확인 방법세션 밖 실행에 BLOCK 이 나는가호스트가 컨테이너가 쓴 파일을 직접 실행하면 write_exec_boundary 의 BLOCK 과 would_kill 이 쓴 세션 로그에 남음실제 로더, verdicts.jsonl만료된 태그는 어떻게 다루나쓴 지 10분을 넘으면 세션 밖 실행도 SUSPECT (사용자 결정)단위 테스트의 경계 검사..

요약2일차는 세션이 쓴 파일을 다른 주체가 실행하면 TAG_HIT 이벤트가 세션 로그에 남는 경로를 C 프로브로 구현하고 VM 에서 확인했다. 판정(BLOCK)은 아직 없고 이벤트가 올라오는 것까지가 이번 범위다. 아래 결과는 모두 사용자 VM 출력으로 확인한 것이다. 질문결과확인 방법세션이 쓴 파일이 맵에 기록되는가write_tags 에 (40, ino) 와 (265289730, ino) 두 쌍이 들어가고 값의 cgroup 이 세션의 값과 같음. 호스트에서 쓴 파일은 안 들어감bpftool map dump name write_tags태그된 파일이 실행되면 이벤트가 나오는가컨테이너 안 실행 1줄(exec_cgroup_id = cgroup_id), 호스트에서 upperdir 경로로 실행 1줄(exec_cg..

요약1일차는 /tmp/trigger 관측 누락을 재현하지 못했고, 에이전트 환경과 파일 신원 키를 실험으로 정했다. 모든 결과는 사용자 VM의 출력으로 확인한 것이고, 추정은 따로 표시했다. 질문결과확인 방법; true 없이 /tmp/trigger 가 안 보이는가현재 빌드에서 재현 안 됨. 38회 관측, 누락 0회, 원인 미규명로더 직접 실행, 러너 경유 반복에이전트는 무슨 권한인가사용자 네임스페이스 안 root, 전체 capability, 호스트 기준 uid 1000id, /proc/self/status훅 후보가 이 커널에 있는가security_file_open, security_bprm_check, sched_process_exec, BTF 모두 있음kallsyms, tracefs, /sys/kern..

오늘 한 일 한눈에 보기4일차까지는 "로그가 잘 쌓인다"를 눈으로 확인했습니다. 5일차는 그 확인을 명령 하나로 반복 가능한 테스트로 바꾼 날입니다. 시나리오를 컨테이너에서 실행하고, 쌓인 로그를 기대값과 비교해서 PASS/FAIL을 내는 러너와 판정기를 만들었고, 그 테스트 자체가 믿을 만한지까지 검증했습니다. 구분내용만든 것tools/judge.sh(판정기), run_scenarios.sh(러너), tools/test_judge.sh, tools/test_runner.sh(테스트의 테스트), tools/mock/(가짜 로더와 가짜 agent-run), tools/fixtures/(실제 로그 표본 7종), scenarios/s00_benign, scenarios/s99_dummy_block기존 코드 변..

오늘의 목표: 판정이 나온 뒤의 "처리 계층"3일차까지는 이벤트를 보고 판정을 내리는 데까지 만들었다. 4일차는 그 판정을 받아서 처리하는 쪽을 만든다. 탐지 로직은 여전히 더미이고, 결과물은 판정이 어디로 가서 무엇을 일으키는지다.3일차까지의 문제판정이 나오면 화면에 JSON 한 줄을 출력하는 것이 전부였다.탐지기 → 판정 → 화면 출력 (끝)화면에 찍히고 사라지니 나중에 검토할 기록이 없다.여러 세션의 판정이 한 화면에 섞여서 어느 세션의 것인지 구분이 안 된다.BLOCK이 나와도 아무 대응이 없다.4일차의 목표탐지기 → 판정 → [판정 수집기] → 세션별 로그 파일에 기록 └→ BLOCK 이면 → kill 스텁 호출 만드는 것역할이유판정 수집기 (handle_v..