การตั้งค่ากฎ AppArmor Unix Socket ต้องกำหนดให้ครบทั้งสองฝั่ง
เรียนรู้วิธีเขียนนโยบายความปลอดภัย AppArmor สำหรับ Unix domain sockets ให้ครอบคลุมทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์ พร้อมข้อควรระวังเรื่องป้ายกำกับ peer

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Unix domain sockets มักใช้เป็นช่องทางควบคุมบริการภายในระบบท้องถิ่น
- การอนุญาตเพียงฝั่งเดียวใน AppArmor ถือว่านโยบายความปลอดภัยยังไม่สมบูรณ์
- ซ็อกเก็ตมีทั้งแบบไฟล์พาธ แบบนามธรรม (abstract) และแบบไม่ระบุตัวตน
- การทดสอบนโยบายต้องใช้ป้ายกำกับของ peer ตัวจริงและตรวจสอบบันทึกการตรวจสอบ
Unix domain sockets ทำหน้าที่เป็นช่องทางการสื่อสารที่ใช้บ่อยสำหรับบริการภายในเครื่อง โดยมักจะข้ามการตรวจสอบเครือข่าย พึ่งพาสิทธิ์ในระบบไฟล์ หรือใช้งานชื่อแบบนามธรรมที่ไม่ปรากฏเป็นไฟล์จริง แม้ว่าระบบ AppArmor จะสามารถเข้ามาช่วยควบคุมการเชื่อมต่อเหล่านี้ด้วยกฎ Unix socket ที่ละเอียดอ่อน แต่นโยบายที่จะอนุญาตให้เพียงฝั่งใดฝั่งหนึ่งของการสนทนาก็ยังไม่ใช่มาตรการที่สมบูรณ์
เอกสารของ AppArmor apparmor.d(5) ได้อธิบายถึงการควบคุมซ็อกเก็ตแบบอิงระบบไฟล์ แบบนามธรรม และแบบไม่ระบุตัวตน โดยกฎเหล่านี้สามารถแยกแยะที่อยู่ของซ็อกเก็ต ป้ายกำกับของ peer และการดำเนินการได้ ในระบบที่มีการควบคุมอย่างละเอียด กฎเครือข่ายแบบหยาบในรุ่นเก่าจะถูกแปลงเป็นกฎซ็อกเก็ตที่เทียบเท่า ซึ่งช่วยให้การแยกบริการภายในเครื่องมีประสิทธิภาพยิ่งขึ้น หากมีการทดสอบนโยบายกับตัวตนของ peer ที่ใช้งานจริง

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ซ็อกเก็ตแบบอิงระบบไฟล์จะมีพาธที่ชัดเจน ในขณะที่ซ็อกเก็ตแบบนามธรรมจะมีที่อยู่ภายในเนมสเปซแบบนามธรรมและไม่มีรายการไดเรกทอรีที่ถาวร แม้โปรไฟล์จะสามารถจับคู่รูปแบบที่อยู่ได้ แต่อย่างเดียวก็ไม่สามารถยืนยันได้ว่า peer นั้นมีความน่าเชื่อถือ ป้ายกำกับ AppArmor ของ peer จึงเป็นสัญญาณแยกต่างหากที่นโยบายความปลอดภัยควรพิจารณาร่วมด้วยเมื่อแพลตฟอร์มรองรับ
การทำความเข้าใจสถาปัตยกรรมของ Unix domain sockets และความสัมพันธ์ระหว่างกระบวนการต่างๆ บนลินุกซ์ถือเป็นหัวใจสำคัญ เพราะช่องทางการสื่อสารเหล่านี้มักถูกมองข้ามเมื่อเทียบกับเครือข่าย TCP/IP ภายนอก การจำกัดสิทธิ์ด้วย AppArmor จึงช่วยอุดรอยรั่วที่กระบวนการผู้ดูแลระบบหรือแอปพลิเคชันอื่นอาจใช้เข้ามาเข้าถึงบริการเบื้องหลังที่สำคัญได้
เอกสารยังระบุว่าการจับคู่รูปแบบจะปฏิบัติตามกฎพาธไฟล์ซึ่งอาจทำให้ผู้เขียนนโยบายประหลาดใจได้ สัญลักษณ์ตัวแทนที่ดูเหมือนจะตรงกับไดเรกทอรีหนึ่งระดับอาจไม่ตรงกับเครื่องหมายทับภายในที่อยู่ ชื่อแบบนามธรรมก็มีรูปแบบการแสดงผลของตนเองเช่นกัน ดังนั้นจึงไม่ควรคัดลอกรูปแบบพาธไฟล์ไปใช้กับกฎซ็อกเก็ตแบบนามธรรมโดยคิดว่าความหมายจะยังคงเดิม
เมื่อบริการเปิดพอร์ตฟังบนซ็อกเก็ต จำเป็นต้องปกป้องทั้งพาธการฟังและพาธการเชื่อมต่อ ไคลเอนต์อาจได้รับอนุญาตให้เชื่อมต่อในขณะที่เซิร์ฟเวอร์ก็ได้รับอนุญาตให้ยอมรับการเชื่อมต่อจาก peer ใดก็ได้ ซึ่งอาจทำให้ไคลเอนต์ที่ถูกเจาะระบบสามารถติดต่อกับบริการที่มีสิทธิ์สูงกว่าที่โปรไฟล์ไม่ได้ตั้งใจให้เข้าถึงได้
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น