요약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..

오늘의 목표: 출력만 하던 로더를 "판정하는 구조"로2일차까지는 로더가 ring buffer에서 이벤트를 받아 JSON으로 찍기만 했다. 3일차의 목표는 이 사이에 디스패처와 탐지기를 끼워 넣어, 이벤트가 "위험한가"를 판단하는 구조의 뼈대를 만드는 것이다. 탐지 로직은 없고(더미 탐지기 2개뿐), 새 탐지기를 파일 하나로 추가할 수 있는 구조와 그것을 검증하는 단위 테스트까지가 범위다.구조의 변화원래 흐름은 "이벤트 → 출력"이었다.이벤트 → handle_event() → JSON 출력3일차 이후에는 이렇게 된다.이벤트 → handle_event() → 디스패처 → 탐지기들 → 판정 → (출력 / 로그 / kill switch) 단계하는 일3일차 구현handle_event()ring buffer에서 이..