- ทีมความปลอดภัยของเคอร์เนลลินุกซ์ จะแก้ไขช่องโหว่ที่มีการรายงานเข้ามาให้เร็วที่สุดเท่าที่จะทำได้ และรวมเข้ากับรีโพสาธารณะโดยไม่ออกประกาศหรือแถลงการณ์แยก
- ทีมนี้ แยกจากทีม Kernel CVE ที่รับผิดชอบการออก CVE โดยสิ้นเชิง และทุกคนทำงานในฐานะบุคคล ไม่ได้ดำเนินงานในนามบริษัทสังกัด
- บั๊กด้านความปลอดภัย ถูกปฏิบัติเช่นเดียวกับบั๊กทั่วไป และหลังแก้ไขแล้วจะไม่ถูกระบุแยกเป็น ‘แพตช์ความปลอดภัย’
- จะ ไม่คงสถานะปิดไว้ (embargo) เกิน 7 วัน และการแก้ไขส่วนใหญ่จะถูกเปิดเผยทันที
- แนวทางนี้สะท้อนถึง ลักษณะของโอเพนซอร์สและสภาพแวดล้อมการใช้งานที่หลากหลาย เพื่อคงไว้ซึ่งความโปร่งใสและความเป็นอิสระของการตอบสนองด้านความปลอดภัยของเคอร์เนล
บทบาทของทีมความปลอดภัยของเคอร์เนลลินุกซ์
- ทีมความปลอดภัยของเคอร์เนลคือกลุ่มนักพัฒนาที่ทำหน้าที่ จัดประเภทบั๊กความปลอดภัยที่อาจเกิดขึ้นซึ่งมีการรายงานเข้ามา และแก้ไขอย่างรวดเร็ว
- พวกเขารับผิดชอบการตอบสนองด้านความปลอดภัยแบบ เชิงรับ (reactive) แยกจากมาตรการป้องกันระยะยาวที่ Kernel Self-Protection Project ดำเนินการ
- ขั้นตอนการรายงานทำผ่าน อีเมลข้อความล้วน ที่เรียบง่าย โดยไม่อนุญาต HTML, ไฟล์แนบแบบไบนารี หรือการเข้ารหัส
- รายงานที่เข้ารหัสไม่สามารถจัดการได้เนื่องจากโครงสร้างการส่งถึงผู้รับหลายคน
- สมาชิกทีมเป็นนักพัฒนาหลักที่เป็นตัวแทนของซับซิสเต็มสำคัญต่าง ๆ ของเคอร์เนล และ ไม่สามารถแชร์เนื้อหาการหารือกับนายจ้างหรือบุคคลภายนอกได้
- ความเป็นอิสระนี้ทำให้สามารถตอบสนองได้อย่างสม่ำเสมอโดยไม่ขึ้นกับข้อกำหนดทางกฎหมายของหลายประเทศ (เช่น CRA)
ขั้นตอนการแก้ไขบั๊ก
- หากบั๊กที่รายงานเกี่ยวข้องกับซับซิสเต็มใด จะเพิ่ม ผู้ดูแลซับซิสเต็ม นั้นเข้ามาในวงสนทนาทางอีเมลเพื่อร่วมแก้ไข
- ในกรณีของซับซิสเต็มที่มีปัญหาเกิดซ้ำ ผู้ดูแลอาจเข้าร่วมอยู่ในเมลลิงลิสต์ของทีมความปลอดภัยโดยตรง
- หากผู้รายงานส่งแพตช์แก้ไขมาด้วย ก็จะได้รับการยกย่องผลงาน หากไม่มี นักพัฒนาจะจัดการแก้ไขกันเอง
- เมื่อแก้ไขเสร็จแล้ว จะ รวมเข้ากับเมนเคอร์เนลบรานช์และรีลีส stable
นโยบายการปิดข้อมูล (Embargo)
- ไม่อนุญาตให้มีระยะเวลาปิดข้อมูลเกิน 7 วัน และการแก้ไขส่วนใหญ่จะเปิดเผยทันที
- หลังจากแก้ไขแล้ว ผู้รายงานสามารถประกาศต่อภายนอกได้หากต้องการเท่านั้น และ ตัวทีมความปลอดภัยเองจะไม่ออกประกาศใด ๆ
- การจัดสรร CVE จะดำเนินการในภายหลังโดย ทีม Kernel CVE ซึ่งเป็นคนละทีมกับทีมความปลอดภัย
หลักการ “บั๊กก็คือบั๊ก”
- ในปี 2008 Linus Torvalds ระบุอย่างชัดเจนว่าไม่ควรทำเครื่องหมายบั๊กด้านความปลอดภัยแยกต่างหาก
- เพราะการแบ่งว่าเป็น “การแก้ไขด้านความปลอดภัย” ทำให้ความสำคัญของบั๊กอื่น ๆ บิดเบือนไป
- การแก้ไขบั๊กทั้งหมดมีความสำคัญเท่าเทียมกัน และ ไม่ว่าจะเป็นด้านความปลอดภัย ฟังก์ชันการทำงาน หรือประสิทธิภาพ ก็ถูกนำเข้าทันทีเหมือนกันทั้งหมด
เหตุผลที่ไม่มีประกาศด้านความปลอดภัย
- บั๊กแทบทุกอย่างในระดับเคอร์เนล อาจกลายเป็นปัญหาด้านความปลอดภัยได้
- มีได้หลายรูปแบบ เช่น หน่วยความจำรั่ว การปฏิเสธการให้บริการ และการรั่วไหลของข้อมูล
- ด้วยลักษณะของโอเพนซอร์ส นักพัฒนา ไม่อาจรู้สภาพแวดล้อมจริงของผู้ใช้ได้
- สิ่งที่เป็นการแก้ไขเล็กน้อยสำหรับผู้ใช้รายหนึ่ง อาจเป็นช่องโหว่ร้ายแรงสำหรับอีกรายหนึ่ง
- ดังนั้นนโยบายจึงเรียบง่าย
- บั๊กที่ทราบแล้วต้องแก้ไขทันที
- รีลีสที่แก้ไขแล้วต้องกระจายออกไปให้เร็วที่สุด
- มุมมองของทีมคือ แทนที่จะกังวลว่า “การแก้ไขอาจก่อปัญหาได้” การปล่อย บั๊กที่รู้ว่ามีอยู่ค้างไว้มีความเสี่ยงมากกว่า
ประเด็นความปลอดภัยด้านฮาร์ดแวร์
- กรณีอย่าง Spectre และ Meltdown ซึ่งครอบคลุมทั้ง OS และฮาร์ดแวร์ จำเป็นต้องมีขั้นตอนพิเศษ
- เพื่อรองรับเรื่องนี้จึงมี ‘Hardware Security Policy’ ที่ให้ทำงานร่วมกันผ่านเมลลิงลิสต์เข้ารหัสแบบจำกัดวง
- กระบวนการนี้ช้าและซับซ้อน แต่ช่วงหลังบั๊กฮาร์ดแวร์จำนวนมากก็ ได้รับการแก้ไขโดยไม่ต้องผ่านขั้นตอนนี้
- ในอนาคต ข้อกำหนดเรื่องเวลาตอบสนองของกฎหมาย CRA จะยิ่งทำให้การปิดข้อมูลระยะยาวทำได้ยากขึ้น
ที่มาของการก่อตั้งทีมความปลอดภัยของเคอร์เนล
- ก่อนปี 2005 ยังไม่มีช่องทางติดต่อด้านความปลอดภัยอย่างเป็นทางการ
- การรายงานเกิดขึ้นผ่านเครือข่ายไม่เป็นทางการระหว่างนักพัฒนาเท่านั้น
- ในปี 2005 การหารือเริ่มต้นจากอีเมลข้อเสนอของ Steve Bergman และ
Chris Wright ได้เขียนแพตช์เพื่อเพิ่มข้อมูลติดต่อด้านความปลอดภัยและเอกสารประกอบ
- หลังจากนั้น อีเมลนามแฝงกลาง (security@kernel.org) ก็ถูกทำให้เป็นทางการ
การไม่มีประกาศด้านความปลอดภัยและการแจ้งเตือนล่วงหน้า
- ทีมความปลอดภัยของเคอร์เนล ไม่ได้ดำเนินการประกาศด้านความปลอดภัยหรือรายชื่อแจ้งเตือนล่วงหน้าทุกรูปแบบ
- การกำหนด CVE ID เป็นหน้าที่ของทีม Kernel CVE และทีมความปลอดภัยไม่เกี่ยวข้อง
- แม้จะมีคำขอให้ทำรายชื่อแจ้งเตือนล่วงหน้าอยู่มาก แต่ก็ ไม่มีอยู่จริงเพราะความเสี่ยงในการรั่วไหลและหลักการเรื่องความเป็นสาธารณะ
- มีจุดยืนว่า “ถ้ารัฐบาลยอมให้ทำเช่นนั้นได้ โครงการนั้นก็คงไม่ถูกใช้งานจริง”
1 ความคิดเห็น
ความเห็นจาก Hacker News
ช่วงนี้เทคโนโลยีที่ทำให้ ประสบการณ์การทำ virtualization บนลินุกซ์เดสก์ท็อปราบรื่นขึ้นกำลังพัฒนาอย่างรวดเร็ว
ไดรเวอร์ GPU รองรับ native context ผ่าน Mesa แล้ว และ ความสามารถในการแชร์ ระหว่าง guest–host ของ Wayland ก็กำลังดีขึ้นด้วย
เมื่อก่อนต้องพึ่งการพาร์สโปรโตคอลที่ซับซ้อนอย่าง sommelier หรือ wayland-proxy-virtwl แต่ตอนนี้โปรเจ็กต์ wl-cross-domain-proxy กำลังทำสิ่งนี้ได้อย่างถูกต้อง
VMM ที่ใช้ความสามารถเหล่านี้มี muvm และโซลูชันที่รวมทั้งหมดเข้าด้วยกันคือ munix
ถ้าย้ายเครื่องเสมือนแบบหยุดชั่วคราว ส่งไป แล้วกลับมาทำงานต่อได้ก็คงเจ๋งมาก
นี่จึงเป็นเหตุผลว่าทำไม Red Hat ยังสำคัญอยู่แม้ในปี 2025
งานโครงสร้างพื้นฐานแบบนี้ยังไงก็จำเป็นเสมอ
ตอนที่ Red Hat เลือก cherry-pick คอมมิตด้านความปลอดภัย ถ้าฝั่ง upstream ไม่บอกว่าคอมมิตไหนเกี่ยวกับความปลอดภัย แล้วจะรู้ได้อย่างไร?
บางครั้งก็ฝันถึง OS ที่ปลอดภัยสมบูรณ์แบบ 100%
บางที formal verification หรือ Rust อาจเป็นกุญแจสำคัญ
อยากมั่นใจว่าจะไม่โดนแฮ็ก
ท้ายที่สุดมนุษย์เองนี่แหละคือช่องโหว่ที่ใหญ่ที่สุด
ถึงขั้นมีการตรวจสอบความถูกต้องของ assembly และ Dafny ก็เกิดมาจากที่นี่
แต่ในตลาด “ปล่อยให้เร็ว” มาก่อน “คุณภาพที่ดี” อยู่แล้ว ดังนั้นกว่าความคิดแบบนี้จะกลายเป็นกระแสหลักก็คงต้องใช้เวลาอีกหลายสิบปี
ถ้าต้องการการแยกกั้นจริง ๆ ก็ต้องใช้ virtualization หรือแยกเครื่องจริงทางกายภาพ
เพราะแบบนี้จึงยากที่จะรวบรวมผู้มีส่วนร่วมจำนวนมากให้กับ “OS ที่ปลอดภัย 100%”
ถึงอย่างนั้น ถ้าสนใจเรื่องนี้ก็ยังมีหลายโปรเจ็กต์พัฒนา OS ให้ศึกษา
ความปลอดภัยคือการแข่งขันที่ไม่มีวันจบ
อีกด้านหนึ่ง แม้จะเป็นปี 2026 แล้ว เว็บไซต์ส่วนตัวของ Greg ก็ยังไม่รองรับ TLS
การตั้งค่าด้วย Caddy นั้นง่าย แต่ถ้าเป็นเว็บสแตติกอย่างบล็อกส่วนตัว ประโยชน์เชิงปฏิบัติของการเข้ารหัสแทบไม่มี
ยังไงชื่อโดเมนและ IP ก็ถูกเปิดเผยเป็นข้อความปกติอยู่ดี เลยไม่ได้ต่างกันมาก
ถ้าพวกเขาคิดแบบนั้นจริง ๆ ก็ควร ถอด CNA ออก ไม่ใช่หรือ?
แต่นักวิจัยบางคนมีแนวโน้มจะไล่เพิ่ม จำนวน CVE จึงพยายามให้บั๊กที่แทบไม่อันตรายได้ความสำคัญสูง
“ถ้าจะบังคับให้ใช้การเข้ารหัสเพื่อรายงานปัญหาความปลอดภัย ก็ควรทบทวนนโยบายนี้เสียใหม่ (กำลังพูดถึงรัฐบาลสหราชอาณาจักร)”
ตรงนี้ขำดี
คำพูดที่ว่า “บั๊กก็เป็นแค่บั๊ก” มันง่ายเกินไป
DoS ที่ต้องใช้สิทธิ์ root กับ การยึดระบบจากผู้ใช้ที่ไม่มีสิทธิ์พิเศษ เป็นคนละเรื่องกันโดยสิ้นเชิง
บั๊กบางตัวก่อให้เกิด การละเมิดขอบเขตความปลอดภัย อย่างชัดเจน และควรถูกจัดเป็นบั๊กด้านความปลอดภัย
เรื่องนี้มีคนอธิบายให้ Greg ฟังมาหลายสิบปีแล้ว
สรุปคือ ถ้าไม่ได้รันเวอร์ชันล่าสุด เคอร์เนลก็ยังอยู่ในสภาพที่แพตช์ไม่ครบ
CVE ถูกหลีกเลี่ยง และการแก้ช่องโหว่ก็ ซ่อนอยู่ใน commit log ซึ่งผู้โจมตีก็ดูออก
ไม่เข้าใจว่าทำไมต้องย้ำประเด็นนี้เป็นพิเศษ
ลูกค้าขอแพตช์ที่เกี่ยวกับเคอร์เนลใน Docker image
ทั้งที่ Docker ไม่ได้รวมเคอร์เนลมาด้วย
น่าจะต้องมีวิธีแจกจ่าย image โดยไม่พ่วงประเด็นเคอร์เนล
base image ทั่วไปไม่ได้รวมเคอร์เนลมาอยู่แล้ว