ข้ามไปเนื้อหาหลัก

การตั้งค่ากฎ AppArmor Unix Socket ต้องกำหนดให้ครบทั้งสองฝั่ง

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

เรียบเรียงโดย AI
Inewgen
สด11 Nov 2026ที่มา: Dev.to2 นาทีอ่าน (0 ครั้ง)
แชร์
การตั้งค่ากฎ AppArmor Unix Socket ต้องกำหนดให้ครบทั้งสองฝั่ง

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

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

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

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

linux terminal command line interface dark screen

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

ซ็อกเก็ตแบบอิงระบบไฟล์จะมีพาธที่ชัดเจน ในขณะที่ซ็อกเก็ตแบบนามธรรมจะมีที่อยู่ภายในเนมสเปซแบบนามธรรมและไม่มีรายการไดเรกทอรีที่ถาวร แม้โปรไฟล์จะสามารถจับคู่รูปแบบที่อยู่ได้ แต่อย่างเดียวก็ไม่สามารถยืนยันได้ว่า peer นั้นมีความน่าเชื่อถือ ป้ายกำกับ AppArmor ของ peer จึงเป็นสัญญาณแยกต่างหากที่นโยบายความปลอดภัยควรพิจารณาร่วมด้วยเมื่อแพลตฟอร์มรองรับ

ไม่อยากพลาดข่าวใหม่?

สมัครรับสรุปข่าวสารใหม่ทางอีเมล ไม่บ่อยจนรำคาญ

โฆษณา

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

เอกสารยังระบุว่าการจับคู่รูปแบบจะปฏิบัติตามกฎพาธไฟล์ซึ่งอาจทำให้ผู้เขียนนโยบายประหลาดใจได้ สัญลักษณ์ตัวแทนที่ดูเหมือนจะตรงกับไดเรกทอรีหนึ่งระดับอาจไม่ตรงกับเครื่องหมายทับภายในที่อยู่ ชื่อแบบนามธรรมก็มีรูปแบบการแสดงผลของตนเองเช่นกัน ดังนั้นจึงไม่ควรคัดลอกรูปแบบพาธไฟล์ไปใช้กับกฎซ็อกเก็ตแบบนามธรรมโดยคิดว่าความหมายจะยังคงเดิม

2ฝั่งที่ต้องกำหนดกฎใน AppArmor
3ประเภทหลักของ Unix sockets

เมื่อบริการเปิดพอร์ตฟังบนซ็อกเก็ต จำเป็นต้องปกป้องทั้งพาธการฟังและพาธการเชื่อมต่อ ไคลเอนต์อาจได้รับอนุญาตให้เชื่อมต่อในขณะที่เซิร์ฟเวอร์ก็ได้รับอนุญาตให้ยอมรับการเชื่อมต่อจาก peer ใดก็ได้ ซึ่งอาจทำให้ไคลเอนต์ที่ถูกเจาะระบบสามารถติดต่อกับบริการที่มีสิทธิ์สูงกว่าที่โปรไฟล์ไม่ได้ตั้งใจให้เข้าถึงได้

ที่มา: Dev.to

ความคิดเห็น

แสดงความคิดเห็น
0/2000

พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้