리눅스 커널 보안 작업

• 리눅스 커널 보안팀은 보고된 취약점을 가능한 한 빨리 수정해 공개 저장소에 병합하며, 별도의 공지나 발표를 하지 않음
• 이 팀은 CVE 발급을 담당하는 커널 CVE 팀과는 별개로, 모두 개인 자격으로 활동하며 기업 소속과 무관하게 운영됨
• 보안 버그는 단순한 일반 버그와 동일하게 취급되며, 수정 후 별도의 ‘보안 패치’로 표시하지 않음
• 7일 이상 비공개(embargo) 를 유지하지 않으며, 대부분의 수정은 즉시 공개됨
• 이러한 접근은 오픈소스 특성과 다양한 사용 환경을 고려한 것으로, 커널 보안 대응의 투명성과 독립성을 유지함

리눅스 커널 보안팀의 역할

• 커널 보안팀은 보고된 잠재적 보안 버그를 분류하고 신속히 수정하는 개발자 그룹
  • 이들은 Kernel Self-Protection Project가 수행하는 장기적 예방 조치와는 별도로 반응형(reactive) 보안 대응을 담당
• 보고 절차는 단순한 텍스트 이메일로 이루어지며, HTML·이진 첨부파일·암호화는 허용되지 않음
  • 암호화된 보고는 다중 수신자 구조로 인해 처리 불가
• 팀 구성원은 주요 커널 서브시스템을 대표하는 핵심 개발자들로, 고용주나 외부에 논의 내용을 공유할 수 없음
  • 이 독립성 덕분에 여러 국가의 법적 요구사항(CRA 등)과 무관하게 일관된 대응 가능

버그 수정 절차

• 보고된 버그가 특정 서브시스템과 관련되면, 해당 서브시스템 유지보수자를 이메일 논의에 포함시켜 해결
  • 반복적으로 문제가 발생하는 서브시스템의 경우, 유지보수자가 보안팀 메일링 리스트에 직접 참여하기도 함
• 리포터가 수정 패치를 제공하면 공로를 인정받음, 없을 경우 개발자들이 자체적으로 해결
• 수정이 완료되면 메인 커널 브랜치와 안정화(stable) 릴리스에 병합

비공개(Embargo) 정책

• 7일을 초과하는 비공개 기간은 허용되지 않음, 대부분의 수정은 즉시 공개
• 수정 후에는 리포터가 원할 경우에만 외부 공지를 할 수 있으며, 보안팀 자체는 어떠한 발표도 하지 않음
• CVE 할당은 이후 커널 CVE 팀이 수행하며, 보안팀과는 별도

“버그는 버그일 뿐” 원칙

• 2008년 Linus Torvalds는 보안 버그를 별도로 표시하지 말아야 한다고 명시
  • “보안 수정”이라는 구분은 다른 버그의 중요성을 왜곡시킨다는 이유
• 모든 버그 수정은 동일하게 중요하며, 보안·기능·성능 구분 없이 모두 즉시 반영

보안 공지 부재의 이유

• 커널 수준의 거의 모든 버그는 잠재적으로 보안 문제가 될 수 있음
  • 메모리 누수, 서비스 거부, 정보 유출 등 다양한 형태 존재
• 오픈소스 특성상 개발자는 사용자의 실제 환경을 알 수 없음
  • 한 사용자에게는 사소한 수정이, 다른 사용자에게는 치명적 취약점일 수 있음
• 따라서 정책은 단순함
  • 알려진 버그는 즉시 수정
  • 수정된 릴리스를 가능한 빨리 배포
• “수정이 문제를 일으킬 수 있다”는 우려보다, 알려진 버그를 방치하는 것이 더 위험하다는 입장

하드웨어 보안 이슈

• Spectre, Meltdown 사례처럼 OS와 하드웨어를 모두 포함하는 문제는 예외적 절차 필요
  • 이를 위해 ‘Hardware Security Policy’ 가 마련되어, 제한된 암호화 메일링 리스트를 통해 협업
• 이 과정은 느리고 복잡하지만, 최근에는 많은 하드웨어 버그가 이 절차 없이 해결됨
• 향후 CRA 법률의 응답 시간 요구로 인해 장기 비공개는 더욱 어려워질 전망

커널 보안팀의 탄생 배경

• 2005년 이전에는 공식적인 보안 연락 창구가 존재하지 않음
  • 개발자 간 비공식 네트워크로만 보고가 이루어짐
• 2005년 Steve Bergman의 이메일 제안으로 논의가 시작되어,
  Chris Wright가 보안 연락처와 문서를 추가하는 패치를 작성
  • 이후 중앙 이메일 별칭(security@kernel.org) 이 공식화

보안 공지 및 사전 알림 부재

• 커널 보안팀은 어떠한 형태의 보안 공지나 사전 알림 리스트도 운영하지 않음
  • CVE ID 할당은 커널 CVE 팀이 담당하며, 보안팀은 관여하지 않음
• 사전 알림 리스트 요청이 많지만, 유출 위험과 공공성 원칙 때문에 존재하지 않음
  • “만약 정부가 이를 허용한다면, 그 프로젝트는 실제로 사용되지 않는 것일 것”이라는 입장