การเปลี่ยนแปลงวิธีเผยแพร่ซอร์สโค้ด RHEL ของ Red Hat
- ในเดือนมิถุนายน 2023 Red Hat ได้ตัดสินใจที่ก่อให้เกิดข้อถกเถียง โดยเปลี่ยนวิธีเผยแพร่ซอร์สโค้ดเบื้องหลัง Red Hat Enterprise Linux (RHEL)
- การตัดสินใจครั้งนี้ทำให้เกิดคำถามมากมายเกี่ยวกับความอยู่รอดในอนาคตของ downstream rebuilds ของ RHEL เช่น Rocky Linux, AlmaLinux และ Oracle Linux
- หลังจากนั้นแต่ละดิสโทรก็ได้ออกมาประกาศเพื่อทำให้ชุมชนคลายกังวล
- ในชุมชนโอเพนซอร์สจำนวนมาก ผู้คนตีความการตัดสินใจของ Red Hat ว่าเป็นอิทธิพลของบริษัทยักษ์ใหญ่ที่ขับเคลื่อนด้วยความโลภ
- ผู้คนกล่าวว่ากำลังย้ายหรือได้ย้ายไปยัง Debian แล้ว เพื่อมองหาที่พึ่งพิง
ความสำคัญและความยากของความปลอดภัย
- ความปลอดภัยเป็นเรื่องยาก น่าเบื่อ ไม่น่าพอใจ และต้องใช้ความพยายามอย่างมากหากต้องการทำให้ถูกต้อง
- Debian ไม่ได้ทุ่มเทความพยายามมากพอในการปกป้องผู้ใช้
การนำ SELinux มาใช้ของ Red Hat และการจัดเตรียมนโยบายเริ่มต้น
- Red Hat ยอมรับการใช้งาน SELinux มานานแล้ว และไม่ได้หยุดเพียงแค่เปิดใช้ฟีเจอร์ในเคอร์เนล
- พวกเขาลงแรงทำงานหนักเพื่อสร้างนโยบาย SELinux เริ่มต้นสำหรับดิสโทร
- นโยบายเหล่านี้ถูกเปิดใช้งานมาเป็นค่าเริ่มต้นใน RHEL และช่วยปกป้องเดมอนและเซิร์ฟเวอร์ต่าง ๆ ที่ใช้งานกันมากที่สุดซึ่งรันเป็นค่าเริ่มต้นบน RHEL
- Apache, nginx, MariaDB, PostgreSQL, OpenSSH และอื่น ๆ ต่างได้รับการปกป้องโดยนโยบาย SELinux ที่มากับดิสโทร RHEL
การใช้นโยบาย SELinux กับคอนเทนเนอร์
- การปกป้องนี้ขยายไปถึงคอนเทนเนอร์ด้วย
- คอนเทนเนอร์กำลังกลายเป็นวิธีที่นักพัฒนาเลือกใช้มากขึ้นเรื่อย ๆ สำหรับการเผยแพร่ซอฟต์แวร์
- การคิดว่าการรันบางอย่างในคอนเทนเนอร์นั้นปลอดภัยโดยเนื้อแท้เป็นความเข้าใจผิด
- ตัวคอนเทนเนอร์เองไม่ได้แก้ปัญหาด้านความปลอดภัย แต่แก้ปัญหาด้านการเผยแพร่ซอฟต์แวร์
- บนดิสโทรที่อิงกับ Red Hat สามารถใช้ podman ซึ่งเป็นทางเลือกของ Docker ที่ให้ข้อดีคือสามารถรันคอนเทนเนอร์ได้โดยไม่ต้องมี daemon และรันแบบ rootless ได้อย่างสมบูรณ์
- Red Hat ไปไกลกว่านั้นอีกขั้นด้วยการใช้นโยบาย SELinux เริ่มต้นที่เข้มแข็งเพื่อแยกคอนเทนเนอร์ออกจากโฮสต์ OS และคอนเทนเนอร์อื่น ๆ
- การใช้นโยบาย SELinux กับคอนเทนเนอร์ช่วยเพิ่มกลไกป้องกันที่แข็งแกร่งขึ้นเพื่อลดความเสี่ยงจากช่องโหว่ในอนาคตที่ยังไม่รู้จัก
ความพยายามของ Red Hat ในการจัดเตรียมนโยบาย SELinux เริ่มต้น
- Red Hat ทราบดีว่าหากไม่ทำงานด้านนโยบายเริ่มต้นเหล่านี้ ผู้ใช้ก็จะไม่ยอมรับเทคโนโลยีนี้ และเซิร์ฟเวอร์นับล้านเครื่องจะยังคงอยู่ในสภาพที่เปราะบาง
- SELinux เป็นเรื่องยาก ทั้งภาษานโยบายและเครื่องมือก็ซับซ้อน คลุมเครือ และไม่น่าดึงดูดพอ ๆ กับการกรอกแบบแสดงภาษี
- อย่างไรก็ตาม ด้วยงานที่ Red Hat ทำ การใช้งาน SELinux บน RHEL จึงแทบจะโปร่งใสสำหรับผู้ใช้ และมอบประโยชน์ด้านความปลอดภัยที่เป็นรูปธรรม
แนวทาง AppArmor ของ Debian
- Debian เป็นแกนหลักของชุมชนโอเพนซอร์ส และมีชื่อเสียงด้านความเสถียรและคลังซอฟต์แวร์ที่กว้างขวาง
- อย่างไรก็ตาม เฟรมเวิร์กความปลอดภัยเริ่มต้นของมันยังมีพื้นที่ให้ปรับปรุงอีกมาก
- การตัดสินใจเปิดใช้ AppArmor เป็นค่าเริ่มต้นตั้งแต่ Debian 10 เป็นก้าวเชิงบวกต่อการปรับปรุงความปลอดภัย แต่ยังขาดตกบกพร่องเพราะถูกนำไปใช้เพียงครึ่ง ๆ กลาง ๆ ทั่วทั้งระบบ
- การพึ่งพา AppArmor และการตั้งค่าเริ่มต้นของ Debian แสดงให้เห็นว่ามีปัญหาเชิงระบบในแนวทางด้านความปลอดภัยของมัน
- AppArmor สามารถมอบความปลอดภัยที่แข็งแกร่งได้หากกำหนดค่าอย่างเหมาะสม แต่การตั้งค่าเริ่มต้นของ Debian ไม่ได้ดึงศักยภาพนั้นออกมาใช้
ปัญหาของ AppArmor บน Debian
- โปรไฟล์เริ่มต้นที่จำกัด: Debian มาพร้อมชุดโปรไฟล์ AppArmor ขั้นต่ำ ทำให้บริการสำคัญจำนวนมากไม่ได้รับการปกป้อง
- ท่าทีเชิงรับแทนเชิงรุก: โมเดลความปลอดภัยของ Debian มักพึ่งพาให้ผู้ใช้เป็นผู้กำหนดนโยบายที่เข้มงวดขึ้นเอง แทนที่จะมอบการตั้งค่าที่ปลอดภัยมาเป็นค่าเริ่มต้น
- การบังคับใช้อย่างไม่สม่ำเสมอ: ต่างจาก SELinux บนระบบ Red Hat, AppArmor ของ Debian ถูกใช้งานเพียงบางส่วน ทำให้เกิดช่องว่างด้านความปลอดภัยที่อาจเป็นปัญหาได้
- การขาดแคลนทรัพยากร: ในฐานะโครงการที่ขับเคลื่อนโดยชุมชน Debian ขาดทรัพยากรในการพัฒนาและดูแลนโยบายความปลอดภัยที่ครอบคลุมแบบเดียวกับที่ Red Hat จัดให้
การรันเวิร์กโหลดคอนเทนเนอร์ผ่าน Docker บน Debian
- การรันเวิร์กโหลดคอนเทนเนอร์ผ่าน Docker บน Debian เป็นเรื่องที่พบได้ทั่วไปมาก
- Docker จะสร้างและโหลดโปรไฟล์ AppArmor เริ่มต้นสำหรับคอนเทนเนอร์ชื่อ
docker-default โดยอัตโนมัติ
- น่าเสียดายที่นี่ไม่ใช่โปรไฟล์ที่แข็งแกร่งมากในเชิงความปลอดภัย และผ่อนปรนเกินไป
- แม้โปรไฟล์นี้จะให้การปกป้องอยู่บ้าง แต่ก็ยังเปิดเผยพื้นผิวการโจมตีจำนวนมาก
ความแตกต่างพื้นฐานระหว่าง AppArmor และ SELinux
- ความแตกต่างพื้นฐานระหว่าง AppArmor และ SELinux อยู่ที่แนวทางต่อการควบคุมการเข้าถึงแบบบังคับ (MAC)
- AppArmor ทำงานบนโมเดลที่อิงตามพาธ ขณะที่ SELinux ใช้ระบบบังคับใช้ชนิดที่ซับซ้อนกว่ามาก
- ความแตกต่างนี้เด่นชัดเป็นพิเศษในสภาพแวดล้อมคอนเทนเนอร์
- SELinux บังคับใช้ชนิดกับออบเจ็กต์ทุกชนิดในระบบ (ไฟล์, โพรเซส, พอร์ต ฯลฯ)
- เมื่อเริ่มคอนเทนเนอร์บนระบบ RHEL ที่รองรับ SELinux คอนเทนเนอร์จะถูกกำหนดชนิด
container_t ทันที ซึ่งเป็นกลไกควบคุมการเข้าถึงที่เข้มงวด
- ชนิด
container_t จะกั้นคอนเทนเนอร์ไว้อย่างมีประสิทธิภาพ ทำให้มันไม่สามารถโต้ตอบกับออบเจ็กต์ที่ไม่ได้ติดป้ายกำกับไว้โดยชัดเจนสำหรับการใช้งานคอนเทนเนอร์ได้
- SELinux ไม่ได้หยุดแค่การบังคับใช้ชนิด แต่ยกระดับการแยกคอนเทนเนอร์ไปอีกขั้นด้วยการใช้ป้ายกำกับ multi-category security (MCS)
- ป้ายกำกับเหล่านี้ทำหน้าที่เป็นชั้นการแยกเพิ่มเติมที่ช่วยรักษาการแยกระหว่างคอนเทนเนอร์ แม้จะอยู่ในชนิดเดียวกัน (
container_t)
- คอนเทนเนอร์แต่ละตัวจะได้รับป้ายกำกับ MCS เฉพาะของตนเอง เพื่อสร้างแซนด์บ็อกซ์ส่วนตัวภายในสภาพแวดล้อม
container_t ที่กว้างกว่า
แนวทางของ AppArmor
- AppArmor ไม่ได้สนใจชนิดหรือหมวดหมู่ แต่เน้นการจำกัดความสามารถของโปรแกรมเฉพาะตามโปรไฟล์ที่กำหนดไว้ล่วงหน้า
- โปรไฟล์เหล่านี้ระบุว่าโปรแกรมสามารถเข้าถึงไฟล์ใดได้บ้างและทำการกระทำใดได้บ้าง
- แนวทางนี้นำไปใช้และทำความเข้าใจได้ง่ายกว่า แต่ไม่มีความละเอียดหรือความสม่ำเสมอทั่วทั้งระบบเทียบเท่ากับการบังคับใช้ชนิดของ SELinux
- ดิสโทร Linux กระแสหลักไม่ได้แจกจ่ายโปรไฟล์ AppArmor ที่ครอบคลุมสำหรับเดมอนเครือข่ายทั่วไปทั้งหมดมาเป็นค่าเริ่มต้น
ผลกระทบในทางปฏิบัติ
- ในสภาพแวดล้อม SELinux คอนเทนเนอร์ที่ถูกเจาะระบบจะเผชิญอุปสรรคอย่างมากในการเข้าถึงหรือส่งผลกระทบต่อระบบโฮสต์หรือคอนเทนเนอร์อื่น ๆ เนื่องจากมีเกราะป้องกันสองชั้นคือการบังคับใช้ชนิดและป้ายกำกับ MCS
- SELinux ให้การแยกที่แข็งแกร่งกว่า แต่ต้องแลกกับความซับซ้อนที่เพิ่มขึ้นและภาระด้านประสิทธิภาพที่อาจเกิดขึ้น
- AppArmor มอบโมเดลความปลอดภัยที่เรียบง่ายและเข้าถึงง่ายกว่า ซึ่งยังคงมีประสิทธิภาพมากได้หากกำหนดค่าอย่างเหมาะสม
- Red Hat ได้ทุ่มเทเพื่อทำให้ SELinux และการใช้งานคอนเทนเนอร์เป็นไปอย่างราบรื่นและง่ายดาย
- ท้ายที่สุดแล้ว การเลือกระหว่าง Debian กับ Red Hat ไม่ได้เป็นเพียงการเลือกระหว่างอิทธิพลขององค์กรกับการพัฒนาที่ขับเคลื่อนโดยชุมชน
- แต่มันยังเป็นการเลือกระหว่างระบบที่ตั้งอยู่บนสมมติฐานที่ดีที่สุด กับระบบที่เตรียมพร้อมรับสถานการณ์ที่เลวร้ายที่สุด
- และในโลกที่เชื่อมต่อกันอย่างสูงในปัจจุบัน น่าเสียดายที่ความมองโลกในแง่ร้ายนั้นเป็นสิ่งจำเป็น
ความเห็นของ GN⁺
- การเปลี่ยนนโยบายการเผยแพร่ซอร์สโค้ด RHEL ของ Red Hat แม้จะเป็นที่ถกเถียง แต่ในมุมมองด้านความปลอดภัยอาจถือเป็นการตัดสินใจที่สมเหตุสมผล
- สำหรับดิสโทร Linux ระดับองค์กร การมีฟีเจอร์ความปลอดภัยที่แข็งแกร่งอย่าง SELinux เป็นสิ่งจำเป็น
- อย่างไรก็ตาม การเปลี่ยนนโยบายของ Red Hat อาจส่งผลลบต่อระบบนิเวศโอเพนซอร์ส และบทบาทของดิสโทรที่ขับเคลื่อนโดยชุมชนอย่าง Debian จะยิ่งมีความสำคัญมากขึ้น
- Debian เป็นที่รู้จักว่าเป็นดิสโทรที่ใช้งานง่ายและยืดหยุ่น แต่จำเป็นต้องเสริมความแข็งแกร่งของฟีเจอร์ความปลอดภัยเริ่มต้น
- แม้ AppArmor จะไม่ทรงพลังเท่า SELinux แต่หากกำหนดค่าอย่างเหมาะสมก็สามารถเป็นโซลูชันด้านความปลอดภัยที่มีประสิทธิภาพได้
- ในระยะยาว อาจจำเป็นต้องมีการพัฒนาเฟรมเวิร์กความปลอดภัยแบบใหม่ที่ผสานข้อดีของ SELinux และ AppArmor เข้าด้วยกัน
- ความปลอดภัยของคอนเทนเนอร์เป็นประเด็นสำคัญอย่างยิ่งในยุคคลาวด์เนทีฟ ดังนั้นทุกดิสโทรควรทุ่มเทมากขึ้นในส่วนนี้
2 ความคิดเห็น
เป็นความจริงที่ AppArmor เข้มงวดน้อยกว่า SELinux..
แต่ก็ยากจะบอกว่านั่นหมายความว่าความปลอดภัยอ่อนแอ
SELinux เข้มงวดเกินไปจนเวลาตั้งค่าเซิร์ฟเวอร์ก็มักปิด SELinux กันแทบทั้งหมด
และสำหรับเดสก์ท็อป ความปลอดภัยก็ไม่ใช่ประเด็นหลักที่ SELinux ให้ความสำคัญ
สิ่งที่จำเป็นคือข้อจำกัดที่เหมาะสมในด้าน UI หรือประสบการณ์ผู้ใช้ รวมถึงขั้นตอนการขอสิทธิ์ยืนยันตัวตนที่เหมาะสม และนี่ก็เป็นคนละเรื่องกับการแยกทรัพยากรแบบ SELinux
ดังนั้นความปลอดภัยของเดสก์ท็อป ไม่ว่าจะเป็นสาย Red Hat หรือสาย Debian ก็ล้วนทำงานบนพื้นฐานของ polkit (PolicyKit) ที่ถูกทำให้เป็นมาตรฐานโดย freedesktop
ความคิดเห็นจาก Hacker News