วิธีตั้งค่าโปรไฟล์ AppArmor สำหรับแอปพลิเคชันที่กำหนดเองบน SUSE SLES 15

หมายเหตุเกี่ยวกับเวอร์ชัน ตรวจสอบเมื่อวันที่ 6 ตุลาคม 2026:ขั้นตอนนี้ใช้ได้กับ SUSE Linux Enterprise Server (SLES) 15 SP7 และระบบ SLE 15 ที่เข้ากันได้ซึ่งใช้ AppArmor เอกสารของ SUSE ระบุว่า AppArmor ติดตั้งและทำงานโดยค่าเริ่มต้นใน SLES 15 SP7 SUSE Linux 16.0 ได้ลบ AppArmor ออกและใช้ SELinux แทน ดังนั้นอย่าใช้คำสั่งด้านล่างกับเวอร์ชัน 16.0 ให้ใช้คู่มือเปรียบเทียบ SUSE Linux 16.0 ของ SUSE และเอกสาร SELinux สำหรับเวอร์ชันนั้นแทน

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

คุณควรเตรียมอะไรบ้างก่อนสร้างโปรไฟล์?

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

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

คุณจะยืนยันได้อย่างไรว่า AppArmor มีอยู่ในเวอร์ชัน SUSE นี้?

ขั้นแรก ตรวจสอบเวอร์ชันของระบบปฏิบัติการและสถานะปัจจุบันของ AppArmor:

cat /etc/os-release
sudo aa-status

ตรวจสอบให้แน่ใจว่าระบบรายงานว่าเป็น SLES 15 SP7 หรือเวอร์ชันอื่นที่มีเอกสารรองรับ AppArmor ใน SLES 15 SP7 คู่มือของ SUSE ระบุว่า AppArmor ติดตั้งและทำงานโดยค่าเริ่มต้น หากไม่พบ คู่มือการติดตั้งของ SUSE จะอธิบายไว้sudo zypper in -t pattern apparmorหากติดตั้งบริการแล้วแต่ไม่ได้ทำงาน ให้ตรวจสอบนโยบายการเริ่มต้นระบบและสถานะบริการก่อนเปิดใช้งาน อย่าปิดใช้งานโมดูลความปลอดภัยเพื่อแก้ไขปัญหาแอปพลิเคชัน โปรดดูคู่มือเริ่มต้นใช้งาน AppArmor สำหรับ SLES 15 SP7และคู่มือเครื่องมือบรรทัดคำสั่ง AppArmor สำหรับ SLES 15 SP7สำหรับรายละเอียดเฉพาะเวอร์ชัน

คุณจะระบุไฟล์ปฏิบัติการที่ AppArmor ควรทำการโปรไฟล์ได้อย่างไร?

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

command -v myapp

สำหรับบริการใดๆ ให้ตรวจสอบคำจำกัดความของหน่วยและรายละเอียดกระบวนการโดยใช้เครื่องมือที่มีอยู่ในระบบของคุณ สคริปต์ตัวเรียกใช้งาน ลิงก์สัญลักษณ์ หรือตัวแปลอาจนำไปสู่ไฟล์ปฏิบัติการที่แตกต่างจากที่คาดไว้ แก้ไขเส้นทางที่ทราบแล้วตามreadlink -f /path/to/myappความเหมาะสม แทนที่เส้นทางสัมบูรณ์ที่ตรวจสอบแล้วในทุกคำสั่งด้านล่าง นี่/usr/local/bin/myappเป็นเพียงตัวอย่างเท่านั้น

ก่อนทำการสร้างโปรไฟล์ โปรดตรวจสอบว่ามีโปรไฟล์อยู่แล้วหรือไม่ใน/etc/apparmor.dSUSE จะจัดเก็บโปรไฟล์ไว้ที่นั่น และชื่อไฟล์มักจะแทนที่เครื่องหมายทับในเส้นทางของไฟล์ปฏิบัติการด้วยจุด ตัวอย่างเช่น/usr/local/bin/myappจะแมปไปยังชื่อไฟล์เช่นusr.local.bin.myappอย่าเขียนทับโปรไฟล์ของผู้จำหน่ายหรือโปรไฟล์ที่ดูแลโดยเครื่องของคุณเองโดยไม่ตรวจสอบก่อน SUSE ยังแสดงรายการโปรไฟล์เพิ่มเติมไว้ใน/usr/share/apparmor/extra-profiles; โปรไฟล์ที่เหมาะสมอาจเป็นจุดเริ่มต้นได้ แต่ยังคงต้องตรวจสอบกับแอปพลิเคชันและเวอร์ชันของคุณ ( เอกสารประกอบที่เก็บโปรไฟล์ของ SUSE )

คุณจะสร้างโปรไฟล์เริ่มต้นอย่างปลอดภัยได้อย่างไร?

เรียกใช้เครื่องมือสร้างโปรไฟล์ในฐานะผู้ดูแลระบบ โดยใช้พาธไฟล์ปฏิบัติการแบบเต็ม:

sudo aa-genprof /usr/local/bin/myapp

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

คุณควรทดสอบการกระทำใดบ้าง และคุณจะพบการปฏิเสธได้จากที่ใด

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

ตรวจสอบข้อความเคอร์เนลและบันทึกการตรวจสอบเพื่อหาเหตุการณ์ของ AppArmor:

sudo journalctl -k | grep -i apparmor

ขึ้นอยู่กับการตั้งค่าการบันทึกของระบบ SUSE ยังชี้ไปยัง/var/log/audit/audit.log, journalctl | grep -i apparmor, และ ด้วยdmesg -Tการที่ไม่พบการจับคู่ในมุมมองบันทึกหนึ่งรายการไม่ได้หมายความว่าโปรไฟล์นั้นถูกต้องเสมอไป ตรวจสอบว่าแอปพลิเคชันได้ถูกใช้งานแล้ว และตรวจสอบบริการบันทึกและตำแหน่งบันทึกอื่นๆ ที่ระบุไว้ อย่าถือว่าโปรไฟล์ที่สร้างขึ้นนั้นผ่านการทดสอบแล้วเพียงเพราะแอปพลิเคชันเริ่มต้นทำงานเพียงครั้งเดียว

คุณควรตรวจสอบและปรับปรุงโปรไฟล์อย่างไร?

ในฐานะผู้ใช้ระดับ root ให้ใช้aa-logprofคำสั่งต่อไปนี้เพื่อประมวลผลเหตุการณ์ที่บันทึกไว้และตอบคำถาม:

sudo aa-logprof

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

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

โปรไฟล์เป็นขอบเขตการควบคุมการเข้าถึง ดังนั้นควรตอบคำถามโดยพิจารณาจากพฤติกรรมของแอปพลิเคชันและข้อกำหนดในการปฏิบัติงาน ไม่ใช่เพียงเพราะปรากฏในบันทึกคู่มือเครื่องมือบรรทัดคำสั่ง AppArmor ของ SUSE SLES 15 SP7อธิบายเครื่องมือบรรทัดคำสั่ง และ ลิงก์ อ้างอิงการสนับสนุนของ SUSE AppArmorไปยังหน้าคู่มือที่เกี่ยวข้อง รวมถึงaa-genprof, , aa-logprofและapparmor_parser

คุณควรเปลี่ยนโปรไฟล์เป็นโหมดบังคับใช้เมื่อใด?

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

sudo aa-enforce /usr/local/bin/myapp
sudo systemctl reload apparmor

SUSE ระบุว่าการโหลดซ้ำจะอ่านโปรไฟล์ใหม่ทั้งหมด/etc/apparmor.dโปรแกรมที่กำลังทำงานอยู่อาจต้องรีสตาร์ทก่อนที่โปรไฟล์ที่อัปเดตจะมีผล ประสานงานการรีสตาร์ทกับเจ้าของบริการและใช้คำสั่งการจัดการบริการที่ถูกต้องสำหรับแอปพลิเคชัน จากนั้นทำซ้ำขั้นตอนการทำงานหลักภายใต้การบังคับใช้แทนที่จะสันนิษฐานว่าความสำเร็จในโหมดร้องเรียนพิสูจน์ได้ว่าขั้นตอนเหล่านั้นจะทำงานได้โดยไม่เปลี่ยนแปลง

คุณจะตรวจสอบผลลัพธ์และแก้ไขปัญหาที่เกิดขึ้นได้อย่างไร?

ตรวจสอบสถานะโปรไฟล์และดูว่ามีการปฏิเสธใหม่เกิดขึ้นหรือไม่หลังจากทำการทดสอบ:

sudo aa-status
sudo journalctl -k | grep -i apparmor

ตรวจสอบให้แน่ใจว่าได้โหลดโปรไฟล์ที่ต้องการแล้วและอยู่ในโหมดบังคับใช้ บริการยังคงทำงานได้อย่างปกติ และงานที่จำเป็นแต่ละอย่างยังคงทำงานได้ หากการบังคับใช้บล็อกการทำงานที่ถูกต้อง ให้รวบรวมเหตุการณ์ที่เกี่ยวข้อง ตรวจสอบว่าการเข้าถึงนั้นจำเป็นจริงหรือไม่ และปรับแต่งโปรไฟล์ให้แคบลง สำหรับการวินิจฉัยอย่างรวดเร็วและควบคุมได้sudo aa-complain /usr/local/bin/myappสามารถเปลี่ยนโปรไฟล์ของโปรแกรมนั้นไปเป็นโหมดร้องเรียนได้ ตรวจสอบ อัปเดต และทดสอบอีกครั้งก่อนที่จะกลับไปใช้โหมดบังคับaa-enforceใช้ โหลดและรีสตาร์ทใหม่ตามต้องการ หลีกเลี่ยงการปิด AppArmor ทั่วโลกหรือการให้สิทธิ์แบบกว้างๆ เพื่อแก้ไขปัญหาอย่างรวดเร็ว

ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยงมีอะไรบ้าง?

• การใช้คำแนะนำในการเผยแพร่ที่ไม่ถูกต้อง:ขั้นตอนการทำงานที่แสดงไว้ที่นี่ใช้สำหรับ SLES 15 AppArmor แต่ SUSE Linux 16.0 ใช้ SELinux แทน ตามคู่มือเปรียบเทียบของ SUSE
• การตรวจสอบประสิทธิภาพของโปรแกรมห่อหุ้มแทนที่จะเป็นโปรแกรมจริง:ตรวจสอบไฟล์ปฏิบัติการที่ทำงานจริง โดยเฉพาะอย่างยิ่งสำหรับบริการและสคริปต์
• การเรียนรู้ที่ไม่เพียงพอ:ฟีเจอร์ที่ยังไม่ได้ทดสอบจะไม่สร้างการเข้าถึงที่สังเกตได้ ดังนั้นโปรไฟล์ที่ไม่สมบูรณ์อาจล้มเหลวในภายหลัง
• การอนุมัติข้อความแจ้งเตือนโดยปราศจากบริบท:สิทธิ์อนุญาตที่เพิ่มเข้ามาทุกรายการควรตอบสนองความต้องการของแอปพลิเคชัน
• อย่าลืมรีสตาร์ท:โหลดโปรไฟล์ใหม่ จากนั้นรีสตาร์ทแอปพลิเคชันที่กำลังทำงานอยู่เมื่อจำเป็น เพื่อให้กระบวนการนำนโยบายไปใช้
• การแก้ไขโดยไม่มีเส้นทางย้อนกลับ:สำรองข้อมูลโปรไฟล์ที่จัดเก็บไว้ในเครื่อง และติดตามการเปลี่ยนแปลงในระบบควบคุมเวอร์ชันหรือกระบวนการจัดการการกำหนดค่าของระบบของคุณ

เอกสารอ้างอิงอย่างเป็นทางการจาก SUSE

• คู่มือเริ่มต้นใช้งาน AppArmor สำหรับ SLES 15 SP7
• คู่มือเครื่องมือบรรทัดคำสั่ง AppArmor สำหรับ SLES 15 SP7
• เอกสารประกอบเกี่ยวกับที่เก็บโปรไฟล์ SUSE
• เอกสารอ้างอิงการสนับสนุน SUSE AppArmor
• คู่มือเปรียบเทียบ SUSE Linux 16.0

ข้อมูลอ้างอิงเหล่านี้ได้รับการตรวจสอบเมื่อวันที่ 6 ตุลาคม 2569 คำสั่งและรายละเอียดแพ็กเกจอาจแตกต่างกันไปตามเวอร์ชันของผลิตภัณฑ์ โปรดยืนยันเอกสารประกอบสำหรับ Service Pack ของ SLES ที่ติดตั้งไว้ก่อนทำการเปลี่ยนแปลงใดๆ