▲

리눅스 커널 보안 작업

 (kroah.com)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 리눅스 커널 보안팀은 보고된 취약점을 가능한 한 빨리 수정해 공개 저장소에 병합하며, 별도의 공지나 발표를 하지 않음
  • 이 팀은 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 팀이 담당하며, 보안팀은 관여하지 않음
  • 사전 알림 리스트 요청이 많지만, 유출 위험과 공공성 원칙 때문에 존재하지 않음
    • “만약 정부가 이를 허용한다면, 그 프로젝트는 실제로 사용되지 않는 것일 것”이라는 입장
▲
GN⁺ 4일전  [-]
Hacker News 의견들

  • 최근 리눅스 데스크톱에서 가상화 경험을 매끄럽게 만드는 기술들이 빠르게 발전 중임
    GPU 드라이버가 Mesa를 통해 네이티브 컨텍스트를 지원하고, Wayland의 게스트–호스트 간 공유 기능도 개선되고 있음
    예전엔 sommelier나 wayland-proxy-virtwl 같은 복잡한 프로토콜 파싱이 필요했지만, 이제는 wl-cross-domain-proxy 프로젝트가 이를 제대로 구현 중임
    이 기능들을 활용하는 VMM으로는 muvm, 그리고 이들을 통합하는 솔루션으로 munix가 있음

    • 정말 흥미로움. munix를 사용하는 머신 간에 앱을 라이브 마이그레이션할 수 있을지 궁금함
      일시정지 후 전송하고 다시 재개하는 식으로 가상머신을 옮길 수 있다면 멋질 것 같음

  • 이런 이유로 Red Hat은 2025년에도 여전히 중요함
    이런 종류의 인프라 작업은 항상 필요함

    • 오히려 반대 주장을 할 수도 있음
      Red Hat이 보안 관련 커밋을 선택(cherry-pick)할 때, 상류(upstream)에서 어떤 커밋이 보안과 관련 있는지 알려주지 않으면 어떻게 알 수 있겠음?

  • 가끔 100% 보안이 완벽한 OS를 꿈꿔봄
    아마 형식 검증(formal verification) 이나 Rust가 열쇠일지도 모르겠음
    해킹당하지 않는다는 확신을 갖고 싶음

    • “해킹당하지 않는 OS”라니 멋짐. 하지만 결국 사회공학 공격이 남음
      결국 인간 자신이 가장 큰 취약점임
    • 이런 시도는 이미 여러 번 있었음. Microsoft의 Verve OS가 대표적임
      심지어 어셈블리까지 검증되었고, Dafny도 여기서 나왔음
      하지만 시장에서는 ‘좋은 품질보다 빠른 배포’가 우선이라 이런 아이디어가 주류로 가기까지는 수십 년이 걸림
    • 대부분의 경우 보안 버그로 침해되는 격리 기능은 실제로는 관리 편의성 때문에만 쓰임
      진짜 격리를 위해선 가상화나 물리적 분리가 필요함
      그래서 “100% 안전한 OS”에 많은 기여자를 모으긴 어려움
      그래도 이런 주제에 관심 있다면 여러 OS 개발 프로젝트가 있음
    • 그럼 Qubes OS로 가면 됨
    • 인간이 만든 건 인간이 깰 수 있음
      보안은 끝없는 경쟁임

  • 한편 2026년이 되었는데도 Greg의 개인 웹사이트는 아직 TLS를 지원하지 않음

    • 솔직히 Encrypted Client Hello가 널리 지원되기 전까지는 굳이 할 필요가 없다고 생각함
      Caddy로 설정하는 건 쉽지만, 개인 블로그처럼 정적 사이트라면 암호화의 실익이 거의 없음
      어차피 도메인과 IP는 평문으로 노출되니까 큰 차이가 없음

  • 그들이 정말 그렇게 생각한다면 CNA를 제거했어야 하지 않겠음?

    • 그건 곧 “모든 보안 연구자가 커널 취약점을 임의로 정의할 수 있다”는 뜻이 됨
      하지만 일부 연구자는 CVE 개수만 늘리려는 경향이 있어서, 실제로는 무해한 버그에도 높은 우선순위를 부여하려 함

  • “보안 문제를 보고하려면 암호화를 강제한다면, 이 정책을 재고하라(UK 정부를 말하는 거임)”
    이 부분은 그냥 웃김

  • “버그는 버그일 뿐”이라는 말은 너무 단순함
    root 권한이 필요한 DoS와 비권한 사용자에서 시스템 장악은 완전히 다름
    어떤 버그는 명확히 보안 경계 위반을 일으키는데, 이런 건 보안 버그로 분류해야 함
    Greg에게 이건 수십 년째 설명된 내용임
    결론적으로, 최신 버전을 돌리지 않으면 커널은 완전히 패치되지 않은 상태임
    CVE는 기피되고, 취약점 수정은 커밋 로그에 숨겨짐, 공격자는 그걸 보고 알아챔

    • “최신 버전만 패치된다는 건 대부분의 소프트웨어에도 해당되는 얘기 아닌가?”
      왜 굳이 이걸 강조해야 하는지 모르겠음

  • 고객들이 Docker 이미지에서 커널 관련 패치를 요구함
    하지만 Docker는 커널을 포함하지 않는데 말이지
    커널 없이 이미지를 배포할 방법이 있어야 함

    • 리눅스 커널이 컨테이너 이미지에 실수로 포함될 수 있나?
      일반적인 베이스 이미지는 커널을 포함하지 않음
    • 관련 프로젝트로 wolfi-dev를 참고할 만함
답변달기