리눅스 커널 보안팀은 이렇게 일한다

리눅스 커널 보안팀의 일하는 방식

• 리눅스 커널 보안팀은 리액티브(reactive) 방식으로 운영됨. 보고된 버그를 최대한 빨리 고쳐서 공개 트리에 머지하는 게 전부이고, 별도의 보안 공지 같은 건 일절 없음
• 보안팀과 CVE팀은 완전히 별개 조직임. 두 팀 모두 소속 회사와 무관하게 개인 자격으로 활동함
• 버그 리포트는 평문 이메일만 받음. 암호화 불가(이메일 별칭이라 안 됨), HTML이나 바이너리 첨부도 금지. 영국 정부한테 "암호화 필수 정책 좀 재고하라"고 직격탄 날림

버그 수정 프로세스

• 보안팀이 해당 서브시스템 전문가가 아니면, 해당 메인테이너를 이메일 체인에 끌어들여서 같이 해결함
• 특정 서브시스템에서 반복적으로 버그가 터지면, 메인테이너가 보안 별칭에 아예 합류하게 됨. 이렇게 자연스럽게 팀이 커져온 것
• 이상적으로는 버그 리포터가 패치까지 같이 제출하는 건데, 현실은 그렇지 않은 경우가 많음

엠바고? 최대 7일

• 수정이 완료되면 엠바고는 최대 7일까지만 허용됨. 대부분의 경우 엠바고 자체가 "수고 대비 가치가 없다(more bother than it's worth)"는 입장
• 버그 수정 후 보안팀의 역할은 끝남. 공지를 할지 말지는 리포터의 몫이고, CVE 할당은 나중에 CVE팀이 별도로 처리함

"버그는 그냥 버그다" 철학

• 커널 수준에서는 거의 모든 버그픽스가 사용 환경에 따라 보안 이슈가 될 수 있음. 메모리 누수, DoS, 정보 유출 등 전부 해당
• Ben Hawkes의 명언: "하나의 버그가 어떤 배포 환경에서는 치명적이고, 다른 곳에서는 별것 아닌데, 이 두 상태가 동시에 성립한다"
• 커널 개발자들은 사용자의 유스케이스를 모르고, 알고 싶지도 않음. 그래서 정책은 단순함: 알려진 버그는 최대한 빨리 고치고, 릴리스를 최대한 빨리 내보낸다

하드웨어 보안 이슈는 다름

• Spectre/Meltdown 같은 OS와 하드웨어를 동시에 건드리는 문제는 "엠바고 없음" 정책이 안 통했음
• 이런 경우에만 암호화된 제한 메일링 리스트를 만들어서 대응함. 엠바고를 "불만스럽게 참아주는(grumpily tolerated)" 수준
• 참여해본 개발자들 평가: 투박하고, 어색하고, 극도로 느림. 최근에는 이 프로세스 없이 해결되는 하드웨어 이슈가 늘어나는 추세
• EU의 CRA 법안 타임라인 때문에 앞으로 하드웨어 업체들의 장기 엠바고 자체가 불가능해질 수 있음

역사와 사전 공지 정책

• 2005년 Steve Bergman의 이메일이 계기가 되어 공식 보안 연락 체계가 만들어졌고, Chris Wright가 문서화함
• 사전 공지 리스트(pre-announcement list)는 없음. 이유: "그런 리스트는 항상 공개된 것으로 간주해야 하고, 유출이 있기 마련"
• Linus가 2008년에 이 정책에 대해 쓴 이메일 스레드가 있는데, 전체를 읽어볼 가치가 있음