요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Disclosure와 embargo
security-bugs.rst:47-78Kernel security list는 disclosure channel이 아니라 fix를 만드는 channel이다. Publicly 알려진 bug의 robust fix는 즉시 release한다.
아직 공개되지 않은 bug도 fix가 준비되면 가능한 빨리 release하는 것이 원칙이다. Reporter나 영향받는 당사자가 요청하면 release process 시작부터 최대 7 calendar day 미룰 수 있고, criticality 때문에 더 필요하다는 합의가 있을 때 예외적으로 14 calendar day까지 연장할 수 있다.
연기의 유일한 타당한 이유는 QA와 large-scale rollout의 실제 logistics를 조정하는 것이다.
Fix 개발을 위해 trusted individual과 embargo information을 공유할 수 있지만 reporter 허가 없이 fix와 함께 또는 다른 disclosure channel에 공개하지 않는다. Original report, follow-up discussion, exploit, CVE 정보와 reporter identity가 모두 포함된다.
Security list의 관심은 bug를 고치는 데 있다. 제출 정보와 후속 discussion은 embargo 해제 뒤에도 영구적으로 confidential하게 취급한다.
linux-distros와 oss-security coordination
security-bugs.rst:80-104Kernel security team은 kernel fix에 집중하고 distribution issue와 vendor 사이 disclosure coordination은 보통 linux-distros, public disclosure는 oss-security가 담당한다. 세 list는 목적과 policy가 다르다.
Kernel security team의 embargo clock은 fix가 준비된 시점부터 시작하지만 linux-distros는 fix 존재와 관계없이 list에 처음 게시한 시점부터 시작한다.
영향받는 code maintainer가 fix를 받아들이기 전에는 linux-distros에 연락하지 않는다. Distros wiki의 의무를 완전히 이해해야 하며 두 list를 처음부터 동시에 Cc하는 것은 보통 맞지 않는다. Fix acceptance 전에는 linux-distros를 Cc하지 않고, mainline merge 뒤에는 kernel security team을 Cc하지 않는다.
CVE와 NDA
security-bugs.rst:106-117Kernel security team은 CVE를 assign하지 않고 report나 fix에 CVE를 요구하지도 않는다. 불필요한 복잡성과 처리 지연을 피하기 위해서다. Confirmed issue에 CVE가 필요하면 kernel CVE assignment team에 요청한다.
Linux kernel security team은 formal legal body가 아니므로 non-disclosure agreement를 체결할 수 없다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. _securitybugs:
Security bugs
=============
Linux kernel developers take security very seriously. As such, we'd
like to know when a security bug is found so that it can be fixed and
disclosed as quickly as possible. Please report security bugs to the
Linux kernel security team.
The security team and maintainers almost always require additional
information beyond what was initially provided in a report and rely on
active and efficient collaboration with the reporter to perform further
testing (e.g., verifying versions, configuration options, mitigations, or
patches). Before contacting the security team, the reporter must ensure
they are available to explain their findings, engage in discussions, and
run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
As it is with any bug, the more information provided the easier it
will be to diagnose and fix. Please review the procedure outlined in
'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.
The Linux kernel security team can be contacted by email at
<[email protected]>. This is a private list of security officers
who will help verify the bug report and develop and release a fix.
If you already have a fix, please include it with your report, as
that can speed up the process considerably. It is possible that the
security team will bring in extra help from area maintainers to
understand and fix the security vulnerability.
Please send plain text emails without attachments where possible.
It is much harder to have a context-quoted discussion about a complex
issue if all the details are hidden away in attachments. Think of it like a
:doc:`regular patch submission <../process/submitting-patches>`
(even if you don't have a patch yet): describe the problem and impact, list
reproduction steps, and follow it with a proposed fix, all in plain text.
Disclosure and embargoed information
------------------------------------
The security list is not a disclosure channel. For that, see Coordination
below.
Once a robust fix has been developed, the release process starts. Fixes
for publicly known bugs are released immediately.
Although our preference is to release fixes for publicly undisclosed bugs
as soon as they become available, this may be postponed at the request of
the reporter or an affected party for up to 7 calendar days from the start
of the release process, with an exceptional extension to 14 calendar days
if it is agreed that the criticality of the bug requires more time. The
only valid reason for deferring the publication of a fix is to accommodate
the logistics of QA and large scale rollouts which require release
coordination.
While embargoed information may be shared with trusted individuals in
order to develop a fix, such information will not be published alongside
the fix or on any other disclosure channel without the permission of the
reporter. This includes but is not limited to the original bug report
and followup discussions (if any), exploits, CVE information or the
identity of the reporter.
In other words our only interest is in getting bugs fixed. All other
information submitted to the security list and any followup discussions
of the report are treated confidentially even after the embargo has been
lifted, in perpetuity.
Coordination with other groups
------------------------------
While the kernel security team solely focuses on getting bugs fixed,
other groups focus on fixing issues in distros and coordinating
disclosure between operating system vendors. Coordination is usually
handled by the "linux-distros" mailing list and disclosure by the
public "oss-security" mailing list, both of which are closely related
and presented in the linux-distros wiki:
<https://oss-security.openwall.org/wiki/mailing-lists/distros>
Please note that the respective policies and rules are different since
the 3 lists pursue different goals. Coordinating between the kernel
security team and other teams is difficult since for the kernel security
team occasional embargoes (as subject to a maximum allowed number of
days) start from the availability of a fix, while for "linux-distros"
they start from the initial post to the list regardless of the
availability of a fix.
As such, the kernel security team strongly recommends that as a reporter
of a potential security issue you DO NOT contact the "linux-distros"
mailing list UNTIL a fix is accepted by the affected code's maintainers
and you have read the distros wiki page above and you fully understand
the requirements that contacting "linux-distros" will impose on you and
the kernel community. This also means that in general it doesn't make
sense to Cc: both lists at once, except maybe for coordination if and
while an accepted fix has not yet been merged. In other words, until a
fix is accepted do not Cc: "linux-distros", and after it's merged do not
Cc: the kernel security team.
CVE assignment
--------------
The security team does not assign CVEs, nor do we require them for
reports or fixes, as this can needlessly complicate the process and may
delay the bug handling. If a reporter wishes to have a CVE identifier
assigned for a confirmed issue, they can contact the :doc:`kernel CVE
assignment team<../process/cve>` to obtain one.
Non-disclosure agreements
-------------------------
The Linux kernel security team is not a formal body and therefore unable
to enter any non-disclosure agreements.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
보안 버그 보고와 보고자의 협력
1-19Linux kernel 개발자는 보안을 매우 중요하게 다룬다. 보안 버그가 발견되면 가능한 한 빨리 수정하고 공개할 수 있도록 Linux kernel security team에 보고해야 한다.
Security team과 maintainer는 처음 받은 보고서만으로는 부족해 추가 정보를 요청하는 경우가 거의 대부분이다. Version, configuration option, mitigation, patch를 확인하는 추가 시험을 수행하려면 보고자와의 적극적이고 효율적인 협력이 필요하다. 따라서 보고자는 security team에 연락하기 전에 발견 내용을 설명하고 논의에 참여하며 추가 시험을 실행할 수 있는 상태인지 확인해야 한다.
보고자가 신속히 답하지 않거나 발견 내용을 효과적으로 논의하지 못하고 의사소통이 빠르게 개선되지 않으면 해당 보고의 처리가 중단될 수 있다.
보고서에 포함할 정보와 연락 방법
21-41다른 버그와 마찬가지로 정보가 많을수록 원인을 진단하고 수정하기 쉽다. 어떤 정보가 필요한지 확실하지 않다면 Documentation/admin-guide/reporting-issues.rst의 절차를 먼저 검토한다. Exploit code도 매우 유용하며, 이미 공개된 경우가 아니라면 보고자의 동의 없이 배포하지 않는다.
Linux kernel security team의 연락처는 [email protected]이다. 이 주소는 보안 담당자만 참여하는 비공개 mailing list이며, 담당자는 버그 보고를 검증하고 수정 사항을 개발해 배포하는 일을 돕는다. 이미 수정안을 가지고 있다면 보고서에 함께 넣는 것이 처리 속도를 크게 높인다. Security team은 취약점을 이해하고 수정하기 위해 해당 영역 maintainer에게 추가 지원을 요청할 수 있다.
가능하면 attachment 없이 plain-text email을 보낸다. 복잡한 문제의 세부 정보가 attachment 안에만 있으면 인용 문맥을 유지하며 토론하기가 훨씬 어렵다. Patch가 아직 없더라도 일반 patch 제출처럼 문제와 영향, 재현 절차, 제안하는 수정 순서로 내용을 모두 plain text에 작성한다.
공개와 embargo 정보
43-71Security mailing list는 취약점 공개 채널이 아니다. 공개 조정은 아래의 다른 조직과의 조정 절차를 따른다.
견고한 수정이 개발되면 release 절차가 시작된다. 이미 공개적으로 알려진 버그의 수정은 즉시 배포한다.
아직 공개되지 않은 버그도 수정이 준비되는 즉시 배포하는 것이 원칙이다. 다만 보고자나 영향을 받는 당사자가 요청하면 release 절차가 시작된 시점부터 최대 7일 동안 공개를 미룰 수 있다. 버그의 심각성 때문에 시간이 더 필요하다는 데 합의한 예외적인 경우에는 최대 14일까지 연장할 수 있다. 공개를 미룰 수 있는 유일하게 타당한 이유는 QA와 대규모 배포의 물류를 조정하기 위해서다.
수정을 개발하기 위해 embargo 정보를 신뢰할 수 있는 사람과 공유할 수는 있다. 그러나 보고자의 허락 없이는 그 정보를 수정과 함께 또는 다른 공개 채널에 게시하지 않는다. 보호 대상에는 최초 버그 보고서, 후속 논의, exploit, CVE 정보, 보고자의 신원이 포함되며 이에 한정되지 않는다.
Security team의 관심은 버그를 수정하는 데 있다. Security list에 제출된 그 밖의 정보와 후속 논의는 embargo가 끝난 뒤에도 기한 없이 계속 기밀로 취급한다.
다른 공개 조정 조직과의 관계
73-101Kernel 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하지 않는다.
CVE 할당과 비밀유지계약
103-116Security team은 CVE를 할당하지 않으며, 보고나 수정에 CVE를 요구하지도 않는다. CVE 절차가 문제를 불필요하게 복잡하게 만들고 버그 처리를 늦출 수 있기 때문이다. 확인된 문제에 CVE identifier를 받고 싶은 보고자는 Documentation/process/cve.rst에 설명된 kernel CVE assignment team에 요청할 수 있다.
Linux kernel security team은 법적 계약의 당사자가 되는 공식 조직이 아니므로 non-disclosure agreement를 체결할 수 없다.
Security bug 보고 준비
security-bugs.rst:1-45Linux kernel 개발자는 security를 중요하게 다루며 발견된 security bug를 빠르게 고치고 공개하기 위해 kernel security team에 보고받기를 원한다.
Security team과 maintainer는 version, configuration, mitigation과 patch 확인을 위해 초기 report보다 많은 정보와 추가 test를 거의 항상 요구한다. Reporter는 발견 내용을 설명하고 discussion과 test에 능동적이고 빠르게 참여할 수 있어야 한다. 응답이 늦거나 기술적 discussion이 불가능한 report는 communication이 빨리 개선되지 않으면 중단될 수 있다.
재현 절차, 영향, configuration, log와 가능한 fix를 자세히 제공한다. Exploit code는 매우 유용하며 이미 공개된 경우가 아니면 reporter 동의 없이 공개하지 않는다.
[email protected]는 security officer의 private list다. Report를 검증하고 fix를 개발·release하며 필요한 경우 해당 영역 maintainer를 제한적으로 참여시킨다. 이미 fix가 있으면 함께 보내 처리 속도를 높인다.
가능하면 attachment 대신 plain-text email을 보낸다. 일반 patch submission처럼 problem과 impact, reproduction step, proposed fix를 순서대로 적어 context-quoted discussion이 가능하게 한다.