요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Security bug 보고·수정·공개 절차
1-12Linux kernel 개발자는 보안을 매우 중요하게 다룬다. 보안 버그가 발견되면 가능한 한 빨리 수정하고 공개할 수 있도록 Linux kernel security team에 보고해야 한다.
Security team과 maintainer는 처음 받은 보고서만으로는 부족해 추가 정보를 요청하는 경우가 거의 대부분이다. Version, configuration option, mitigation, patch를 확인하는 추가 시험을 수행하려면 보고자와의 적극적이고 효율적인 협력이 필요하다. 따라서 보고자는 security team에 연락하기 전에 발견 내용을 설명하고 논의에 참여하며 추가 시험을 실행할 수 있는 상태인지 확인해야 한다.
보고자가 신속히 답하지 않거나 발견 내용을 효과적으로 논의하지 못하고 의사소통이 빠르게 개선되지 않으면 해당 보고의 처리가 중단될 수 있다.
다른 버그와 마찬가지로 정보가 많을수록 원인을 진단하고 수정하기 쉽다. 어떤 정보가 필요한지 확실하지 않다면 Documentation/admin-guide/reporting-issues.rst의 절차를 먼저 검토한다. Exploit code도 매우 유용하며, 이미 공개된 경우가 아니라면 보고자의 동의 없이 배포하지 않는다.
Linux kernel security team의 연락처는 security@kernel.org이다. 이 주소는 보안 담당자만 참여하는 비공개 mailing list이며, 담당자는 버그 보고를 검증하고 수정 사항을 개발해 배포하는 일을 돕는다. 이미 수정안을 가지고 있다면 보고서에 함께 넣는 것이 처리 속도를 크게 높인다. Security team은 취약점을 이해하고 수정하기 위해 해당 영역 maintainer에게 추가 지원을 요청할 수 있다.
가능하면 attachment 없이 plain-text email을 보낸다. 복잡한 문제의 세부 정보가 attachment 안에만 있으면 인용 문맥을 유지하며 토론하기가 훨씬 어렵다. Patch가 아직 없더라도 일반 patch 제출처럼 문제와 영향, 재현 절차, 제안하는 수정 순서로 내용을 모두 plain text에 작성한다.
Security mailing list는 취약점 공개 채널이 아니다. 공개 조정은 아래의 다른 조직과의 조정 절차를 따른다.
견고한 수정이 개발되면 release 절차가 시작된다. 이미 공개적으로 알려진 버그의 수정은 즉시 배포한다.
아직 공개되지 않은 버그도 수정이 준비되는 즉시 배포하는 것이 원칙이다. 다만 보고자나 영향을 받는 당사자가 요청하면 release 절차가 시작된 시점부터 최대 7일 동안 공개를 미룰 수 있다. 버그의 심각성 때문에 시간이 더 필요하다는 데 합의한 예외적인 경우에는 최대 14일까지 연장할 수 있다. 공개를 미룰 수 있는 유일하게 타당한 이유는 QA와 대규모 배포의 물류를 조정하기 위해서다.
수정을 개발하기 위해 embargo 정보를 신뢰할 수 있는 사람과 공유할 수는 있다. 그러나 보고자의 허락 없이는 그 정보를 수정과 함께 또는 다른 공개 채널에 게시하지 않는다. 보호 대상에는 최초 버그 보고서, 후속 논의, exploit, CVE 정보, 보고자의 신원이 포함되며 이에 한정되지 않는다.
Security team의 관심은 버그를 수정하는 데 있다. Security list에 제출된 그 밖의 정보와 후속 논의는 embargo가 끝난 뒤에도 기한 없이 계속 기밀로 취급한다.
Kernel security team은 kernel 버그를 수정하는 데만 집중한다. 다른 조직은 distribution의 문제를 고치고 운영체제 vendor 사이의 공개 시점을 조정한다. 일반적으로 조정은 linux-distros mailing list가, 공개는 public oss-security mailing list가 담당한다. 두 list의 관계와 절차는 https://oss-security.openwall.org/wiki/mailing-lists/distros 에 설명되어 있다.
세 mailing list는 목적이 서로 다르므로 정책과 규칙도 다르다. Kernel security team에서 허용되는 제한된 embargo 기간은 수정이 준비된 시점부터 시작한다. 반면 linux-distros의 embargo 기간은 수정 준비 여부와 관계없이 list에 최초로 게시한 시점부터 시작한다. 이 차이 때문에 두 집단 사이의 조정은 어렵다.
따라서 잠재적인 보안 문제를 보고할 때는 영향받는 코드의 maintainer가 수정안을 받아들이기 전까지 linux-distros mailing list에 연락하지 말 것을 kernel security team은 강하게 권고한다. 먼저 distros wiki를 읽고 linux-distros에 연락할 때 보고자와 kernel community에 부과되는 요구 사항을 완전히 이해해야 한다.
일반적으로 두 list를 동시에 Cc하는 것도 타당하지 않다. 예외가 있다면 받아들여진 수정이 아직 merge되지 않은 동안 공개 일정을 조정할 때 정도다. 요약하면 수정이 accept되기 전에는 linux-distros를 Cc하지 않고, 수정이 merge된 뒤에는 kernel security team을 Cc하지 않는다.
Security team은 CVE를 할당하지 않으며, 보고나 수정에 CVE를 요구하지도 않는다. CVE 절차가 문제를 불필요하게 복잡하게 만들고 버그 처리를 늦출 수 있기 때문이다. 확인된 문제에 CVE identifier를 받고 싶은 보고자는 Documentation/process/cve.rst에 설명된 kernel CVE assignment team에 요청할 수 있다.
Linux kernel security team은 법적 계약의 당사자가 되는 공식 조직이 아니므로 non-disclosure agreement를 체결할 수 없다.
.. include:: ../disclaimer-ita.rst
:Original: :ref:`Documentation/process/security-bugs.rst <securitybugs>`
.. _it_securitybugs:
Bachi di sicurezza
==================
.. warning::
TODO ancora da tradurre
요약·해설
security-bugs.rst:1-12이탈리아어 원문에는 `TODO ancora da tradurre` warning만 있으므로 그 12줄을 그대로 보존하면서, 같은 v6.18.37 영어 정식 문서의 한국어 전문 전체를 보충했습니다.
보고자는 `security@kernel.org`와 적극적으로 협력하고 plain-text로 영향·재현·수정 정보를 제공해야 합니다. 공개되지 않은 버그의 수정은 원칙적으로 즉시 배포하되 QA와 대규모 rollout 조정을 위해 최대 7일, 예외적으로 14일까지 embargo할 수 있습니다.
Kernel security team은 수정에 집중하며 linux-distros·oss-security와 목적과 시점이 다릅니다. CVE는 별도 kernel CVE assignment team이 담당하고, 비공식 조직인 security team은 NDA를 체결할 수 없습니다.