unix-ctf: Procedural Environments for Unix-Competence Reinforcement Learning

기술 요약: unix-ctf

문제 제기
언어 모델 (LM) 에이전트를 평가하는 현재 터미널 벤치마크는 터미널을 통해 수행되는 일반 프로그래밍과 진정한 유닉스 역량이라는 두 가지 구별되는 능력을 혼동하고 있습니다. 저자들은 기존 벤치마크 (예: Terminal-Bench 2.0, InterCode, Cybench) 가 "터미널 내 코딩"에 치우쳐 있다고 주장합니다. 여기서 OS 내부 구조에 약하지만 Python 에 능통한 해결자는 표준 도구를 래핑하는 스크립트를 작성함으로써 성공할 수 있습니다. 반면, "유닉스 역량"은 범용 프로그래밍에 명확한 대응물이 없는 OS, 셸, 또는 파일 형식 원시 명령어를 활용할 수 있는 능력으로 정의됩니다 (예: POSIX 확장 속성 접근, ELF note 섹션 파싱, 또는 에포크 이전 파일 수정 시간 해석). 이 논문은 이러한 구분이 현재 모호하게 처리되고 있어, 프로그래밍 숙련도는 향상시키지만 반드시 유닉스 유창성을 향상시키지는 않는 학습 파이프라인을 초래한다고 전제합니다.

방법론
유닉스 역량을 격리하고 훈련하기 위해 저자들은 캡처 더 플래그 (CTF) 작업을 위한 절차적 환경 생성기인 unix-ctf를 개발했습니다. 이 시스템은 다단계 파이프라인을 통해 작동합니다.

1. 수확 파이프라인 (Harvest Pipeline): 시스템은 프런티어 모델 탐색 (플래그를 숨기기 위해 Claude Opus 사용) 과 기계적 검증을 번갈아 가며 작업을 생성합니다.

   • 양방향 계약: 작업의 유효성을 보장하기 위해 파이프라인은 엄격한 계약을 강제합니다. "식재 (plant)" 스크립트는 디스크에 플래그의 평문 흔적을 남겨서는 안 되며, "회복 (recovery)" 스크립트는 새로운 디렉토리에서 플래그를 성공적으로 복원해야 합니다.
   • 파이프라인 분해: 이전 접근법 (예: Endless Terminals) 이 LLM 에게 전체 Docker 컨테이너 생성을 요청한 것과 달리, unix-ctf 는 인프라를 분리합니다. 사전 디버깅된 ctf-base 이미지가 시스템 계층을 처리하고, LLM 은 매개변수화된 plant.sh 및 recovery.sh 스크립트 생성으로 제한됩니다. 이 아키텍처 선택은 이식 가능하고 재사용 가능한 변형의 수율을 크게 증가시킵니다.
   • 정규화: 생성된 스크립트는 difflib.SequenceMatcher 를 사용하여 0.85 유사도 임계값으로 중복 제거를 거쳐 기술의 정준 라이브러리를 생성합니다.

2. 환경 생성:

   • 생성기는 정준 라이브러리를 기반으로 새로운 Docker 컨테이너를 인스턴스화합니다.
   • 다중 플래그 전략: 강화 학습 (RL) 에서 희소한 보상 신호를 해결하기 위해, 각 컨테이너는 단일 이진 결과 대신 서로 다른 기술을 사용하여 8 개의 서로 다른 플래그로 시드됩니다.
   • 스티키 풀 스케줄링: 훈련 중 50 개의 기술 풀이 유지됩니다. 각 배치 후, 해결률에 따라 상위 15 개 기술이 교체되어 에이전트가 다양한 기술 분포를 접하도록 하여 특정 계열에 과적합되는 것을 방지합니다.

3. 훈련 프로토콜:

   • 저자들은 LoRA 어댑터를 사용하여 **Group Relative Policy Optimization (GRPO)**으로 Qwen3-8B를 파인튜닝했습니다.
   • 두 가지 초기화 전략을 테스트했습니다: 기본 모델에서 직접 GRPO 를 수행하는 것과 도구 호출 형식을 정렬하기 위해 성공적인 해결자 궤적에 대한 짧은 감독 파인튜닝 (SFT) 패스를 거친 모델에서 GRPO 를 수행하는 것입니다.
   • 훈련은 40 개의 배치를 포함하며, 기술 풀을 회전시켜 모델이 다양한 유닉스 기능 (파일 메타데이터, 이진 형식, IPC, 암호화 등) 에 노출되도록 했습니다.

주요 기여

1. 고수율 절차적 생성기: 파이프라인은 87.5% 의 이식성률(750 개의 원시 시도에서 656 개의 유효 변형) 을 달성하여 Endless Terminals 접근법의 재현 (17.5%) 보다 5 배 향상되었습니다. 이는 인프라와 논리를 분리하고 양방향 계약을 적용한 데 기인합니다.
2. 정준 기술 라이브러리: 이 과정은 16 개 계열 (예: 파일시스템 메타데이터, ELF 내부 구조, X.509 확장, 프로세스 제어) 에 걸친 155 개의 고유한 기술 식별자 라이브러리를 산출합니다. 이러한 기술들은 직접적인 Python 대응물이 없는 OS 기능을 특히 대상으로 합니다.
3. 분리 가능성과 훈련 가능성의 증명: 이 논문은 유닉스 역량이 일반 프로그래밍과 독립적으로 훈련할 수 있는 분리 가능한 기술임을 보여주는 경험적 증거를 제공합니다. unix-ctf 표면에서 파인튜닝하면 홀드아웃 작업에서 성능이 크게 향상되었고 외부 벤치마크에서 모델의 역량이 재분배되었습니다.

결과

• 홀드아웃 성능: 15 가지 기술 다계열 홀드아웃 세트 ($n=225$) 에서 해결률은 11.6%(기본 Qwen3-8B) 에서 43.6%(SFT 초기화 GRPO) 로 증가하여 3.8 배 향상을 보였습니다.
• InterCode-CTF 로의 전이: unix-ctf 훈련은 외부 InterCode-CTF 벤치마크 (100 개 작업) 에서 모델의 성능을 재분배했습니다. 집계 점수는 안정적으로 유지되었지만, 포렌식 카테고리는 기본 초기화 GRPO 로 33 퍼센트 포인트 증가(7% 에서 40% 로) 를 보였으며, 역공학 또한 향상되었습니다. 이는 훈련 표면이 포렌식 분석 및 OS 내부 구조와 관련된 기술을 특히 향상시킨다는 것을 시사합니다.
• 효율성: SFT 초기화 변형은 18 턴 예산을 더 효율적으로 활용했습니다 (평균 12.7 턴 vs 기본 모델의 17.2 턴), 이는 더 나은 작업 인식을 나타냅니다.
• 보상과 전이의 이분화: 저자들은 SFT 초기화 변형이 더 높은 훈련 보상을 달성했지만 기본 초기화 변형에 비해 InterCode-CTF 로의 전이는 낮았음을 관찰했습니다. 이는 훈련 보상을 하류 능력의 유일한 대리 지표로 사용하는 것에 경고를 보냅니다.

의의 및 주장
이 논문은 유닉스 역량은 분리 가능하고 훈련 가능하며, 셸을 통한 일반 프로그래밍 작업에 포함시키기보다 직접 평가하는 것이 최선이라고 주장합니다. 터미널 상호작용의 "유닉스" 구성 요소를 격리함으로써 저자들은 절차적 생성이 현재 벤치마크가 놓치고 있는 파일시스템 메타데이터 및 이진 형식과 같은 과소 대표된 OS 기능을 효과적으로 대상으로 할 수 있음을 입증했습니다. 이 연구는 에이전트의 보안 및 시스템 관리 컨텍스트에서의 성능을 향상시키기 위해 훈련 파이프라인이 일반 터미널 벤치마크에 의존하기보다 이러한 특정 OS 원시 명령어를 명시적으로 대상으로 해야 함을 시사합니다. 이러한 일반 터미널 벤치마크는 주로 프로그래밍 유창성을 측정할 수 있기 때문입니다.

저자들은 범위에 대해 겸손하게 언급하며, 라이브러리는 생성을 위해 LLM 에 의존하므로 (과소 대표된 기술을 놓칠 가능성) 현재 CTF 스타일 작업으로 제한되어 있어 유닉스 관리의 전체 범위를 다루지 못한다고 지적합니다. 그들은 재현을 위한 방법론적 세부 사항을 공개하지만, 공격적 보안 훈련의 장벽을 낮추지 않기 위해 전체 아티팩트 라이브러리는 공개하지 않습니다.