สร้างโปรไฟล์ AppArmor แบบกำหนดเองบน SUSE Linux

SUSE ประกาศเปิดตัว SLES 16.0 เมื่อวันที่ 4 พฤศจิกายน 2025 โดย SELinux จะเข้ามาแทนที่ AppArmor ในฐานะเฟรมเวิร์กควบคุมการเข้าถึงแบบบังคับเริ่มต้น หากเซิร์ฟเวอร์ของคุณใช้งาน SLES 16 อย่าคิดว่า AppArmor ได้รับการติดตั้งหรือทำงานอยู่แล้ว: โปรดตรวจสอบเฟรมเวิร์กที่รองรับโดยการติดตั้งนั้นก่อนที่จะใช้คำสั่งเหล่านี้ ขั้นตอนด้านล่างนี้เป็นไปตามเอกสาร AppArmor ของ SUSE สำหรับ SLES 15 SP7 ซึ่ง AppArmor ได้รับการติดตั้งและทำงานโดยค่าเริ่มต้น

ใน SLES 15 SP7 วิธีการปฏิบัติสำหรับแอปพลิเคชันแบบกำหนดเองคือการaa-genprofสร้างโปรไฟล์เริ่มต้น ทดสอบแอปพลิเคชันในโหมดแจ้งเตือน ตรวจสอบคำขอที่บันทึกไว้แต่ละรายการ จากนั้นยืนยันว่าโปรไฟล์นั้นใช้งานได้ ตัวอย่างนี้ใช้ไฟล์ปฏิบัติการสมมติที่/usr/local/bin/report-worker; โปรดแทนที่ด้วยเส้นทางไฟล์ปฏิบัติการจริงของแอปพลิเคชันของคุณ

ก่อนที่คุณจะเริ่มต้น

โปรไฟล์ AppArmor คือนโยบายข้อความที่จัดเก็บไว้ภายใต้/etc/apparmor.d. apparmor-utilsแพ็กเกจนี้มีเครื่องมือสำหรับการสร้างโปรไฟล์ ตรวจสอบโฮสต์และระบุไฟล์ปฏิบัติการจริง รวมถึงตรวจสอบว่าหน่วย systemd เรียกใช้กระบวนการห่อหุ้มหรือกระบวนการลูกหรือไม่:

sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
หน้าต่างเทอร์มินัลที่แสดงคำสั่ง aa-status บนเชลล์แบบ SUSE Linux Enterprise Server 15 SP7
ภาพแสดงคำสั่งในเทอร์มินัลที่ใช้ตรวจสอบว่า AppArmor ทำงานอยู่ก่อนที่จะทำการสร้างโปรไฟล์

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

สร้างและปรับแต่งโปรไฟล์

  1. เริ่มกระบวนการสร้างโปรไฟล์หยุดแอปพลิเคชันหากกำลังทำงานอยู่ จากนั้นเริ่มการสร้างโปรไฟล์:

    sudo systemctl stop report-worker
    sudo aa-genprof /usr/local/bin/report-worker
    ข้อความแจ้งเตือนในเทอร์มินัลกำลังเริ่มต้น aa-genprof สำหรับไฟล์ปฏิบัติการตัวอย่างที่ /usr/local/bin/report-worker
    ภาพแสดงมุมมองเทอร์มินัลของ aa-genprof ขณะเริ่มต้นโปรไฟล์การเรียนรู้สำหรับไฟล์ปฏิบัติการตัวอย่าง

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

  2. ทดสอบพฤติกรรมการใช้งานจริงเปิดตัวสร้างโค้ดไว้ ในเทอร์มินัลอีกตัวหนึ่ง เริ่มบริการและเรียกใช้งานงานหรือฟีเจอร์ตัวอย่าง:

    sudo systemctl start report-worker
    sudo journalctl -f
    คำสั่งเทอร์มินัลสองคำสั่งสำหรับเริ่มต้นบริการ report-worker ตัวอย่างและบันทึกระบบต่อไปนี้
    ภาพแสดงมุมมองเทอร์มินัลประกอบการเริ่มต้นบริการตัวอย่างและติดตามการทำงานขณะที่บริการทำงานในโหมดการเรียนรู้

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

  3. ตรวจสอบคำขอการเข้าถึงแต่ละรายการกลับไปที่aa-genprofและกดSเพื่อสแกนช่วงบันทึกที่ทำเครื่องหมายไว้ สำหรับทุกข้อความแจ้งเตือน ให้ตัดสินใจว่าแอปพลิเคชันต้องการไฟล์ ความสามารถ หรือการเปลี่ยนผ่านโปรแกรมย่อยนั้นจริงหรือไม่ อนุญาตเส้นทางและสิทธิ์ที่แคบที่สุดที่ใช้งานได้จริง ยอมรับนามธรรมเมื่อครอบคลุมงานทั่วไปได้อย่างถูกต้อง ใช้ glob เฉพาะเมื่อไฟล์ที่ตรงกันมีข้อกำหนดด้านความน่าเชื่อถือและการเข้าถึงเดียวกัน ปฏิเสธหรือข้ามคำขอที่ไม่เกี่ยวข้องหรือไม่สามารถอธิบายได้

    ข้อความแจ้งเตือนในเทอร์มินัลที่เรียกใช้ aa-logprof เพื่อตรวจสอบเหตุการณ์การเข้าถึง AppArmor
    ภาพแสดงมุมมองเทอร์มินัลของ aa-logprof เครื่องมือแบบโต้ตอบสำหรับตรวจสอบคำขอการเข้าถึงที่บันทึกไว้

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

  4. ตรวจสอบนโยบายที่สร้างขึ้นสำหรับเส้นทางตัวอย่างนี้ ข้อกำหนดการตั้งชื่อของ SUSE จะแปลงเครื่องหมายทับในเส้นทางของไฟล์ปฏิบัติการเป็นจุด ทำให้ได้ผลลัพธ์เป็น/etc/apparmor.d/usr.local.bin.report-worker. ตรวจสอบผลลัพธ์แทนที่จะถือว่ากฎที่สร้างขึ้นนั้นปลอดภัยโดยอัตโนมัติ:

    sudo less /etc/apparmor.d/usr.local.bin.report-worker
    แสดงข้อความแจ้งเตือนในเทอร์มินัลขณะเปิดโปรไฟล์ report-worker ที่สร้างขึ้นจาก /etc/apparmor.d
    ภาพแสดงตัวอย่างการเปิดไฟล์โปรไฟล์ในเทอร์มินัล โดยชื่อไฟล์จะต้องตามหลังพาธของไฟล์ปฏิบัติการ

    ตรวจสอบให้แน่ใจว่าชื่อโปรไฟล์ตรงกับไฟล์ปฏิบัติการที่ต้องการ ใช้ไฟล์ include ที่จำเป็น และให้สิทธิ์การเข้าถึงเฉพาะการกำหนดค่า ข้อมูล บันทึก การเชื่อมต่อ และโปรแกรมช่วยเหลือที่แอปพลิเคชันต้องการจริงๆ เท่านั้น หลีกเลี่ยงกฎกว้างๆ เช่น การให้สิทธิ์การเข้าถึงแบบไม่จำกัด/หรือการให้สิทธิ์การเข้าถึงทั้งโครงสร้างไฟล์ที่สามารถเขียนได้เพียงเพื่อปิดเสียงการปฏิเสธ แอปพลิเคชันยังคงขึ้นอยู่กับความเป็นเจ้าของและสิทธิ์การเข้าถึงแบบ Unix ทั่วไป AppArmor เพิ่มเลเยอร์การจำกัดเพิ่มเติมอีกชั้นหนึ่ง

  5. ตั้งค่าโหมดที่ต้องการอย่างชัดเจนหลังจากตรวจสอบแล้ว ให้บังคับใช้โปรไฟล์สำหรับโปรแกรมที่กำหนดเอง:

    sudo aa-enforce /usr/local/bin/report-worker
    ข้อความแจ้งเตือนในเทอร์มินัลแสดงการเปลี่ยนโปรไฟล์ AppArmor ของ report-worker เป็นโหมดบังคับใช้
    ภาพแสดงมุมมองเทอร์มินัลของคำสั่ง aa-enforce ที่ใช้ข้อจำกัดของโปรไฟล์กับโปรแกรมตัวอย่าง

    หากคุณแก้ไขโปรไฟล์ด้วยตนเองหลังจากโปรแกรมสร้างโปรไฟล์ปิดตัวลงแล้ว ให้โหลดชุดโปรไฟล์ใหม่โดยใช้คำสั่ง ` sudo systemctl reload apparmorreload_profile_set` เอกสารของ SUSE อธิบายว่าการโหลดโปรไฟล์ใหม่เป็นการสแกนโปรไฟล์ซ้ำโดยไม่ต้องยกเลิกการจำกัดกระบวนการที่กำลังทำงานอยู่ จากนั้นรีสตาร์ทบริการแอปพลิเคชันเพื่อให้การตั้งค่าใหม่มีผลกับกระบวนการนั้น

ตรวจสอบใบสมัครภายใต้การบังคับใช้กฎหมาย

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

sudo aa-status
sudo journalctl -k -g apparmor --since today
แสดงข้อความแจ้งเตือนในเทอร์มินัล พร้อมเรียกใช้คำสั่ง aa-status เพื่อตรวจสอบสถานะโปรไฟล์ AppArmor
ภาพแสดงมุมมองเทอร์มินัลของการตรวจสอบสถานะที่ใช้เพื่อยืนยันว่าโปรไฟล์ที่กำหนดเองถูกโหลดในโหมดบังคับใช้แล้ว
ข้อความแจ้งเตือนในเทอร์มินัลกำลังกรองรายการบันทึกเคอร์เนลเพื่อหาข้อความ AppArmor
ภาพแสดงมุมมองเทอร์มินัลประกอบการกรองบันทึกเคอร์เนลเพื่อค้นหาเหตุการณ์ AppArmor ระหว่างการตรวจสอบ

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

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

แหล่งที่มา

ฝากความเห็น

เปิดใช้งานการแพตช์สด SLES และตรวจสอบการแก้ไขเคอร์เนล

เปิดใช้งานการแพตช์สด SLES และตรวจสอบการแก้ไขเคอร์เนล

ตั้งค่าเส้นทาง Live Patching ที่ถูกต้องสำหรับ SLES 16.0 หรือ 15 SP7 ใช้การแก้ไขเคอร์เนลที่เหมาะสม และตรวจสอบว่าสิ่งใดทำงานอยู่โดยไม่สับสนกับการอัปเดตเคอร์เนลที่ต้องรีบูตเครื่อง

รักษาระบบให้พร้อมใช้งานระหว่างการอัปเกรด SLES 15 SP5 เป็น SP6

รักษาระบบให้พร้อมใช้งานระหว่างการอัปเกรด SLES 15 SP5 เป็น SP6

SLES 15 SP5 สามารถอัปเกรดแบบออนไลน์เป็น SP6 ได้ แต่แต่ละโหนดจะต้องรีบูต ใช้การอัปเกรดแบบค่อยเป็นค่อยไป (rolling upgrade) หรือการเปลี่ยนระบบแบบสีฟ้า-เขียว (blue-green cutover) ที่ผ่านการทดสอบแล้ว เพื่อให้สามารถเข้าถึงเวิร์กโหลดได้อย่างต่อเนื่อง

สร้างโปรไฟล์ AppArmor แบบกำหนดเองบน SUSE Linux

สร้างโปรไฟล์ AppArmor แบบกำหนดเองบน SUSE Linux

สร้าง ปรับแต่ง และตรวจสอบโปรไฟล์ AppArmor ที่มีสิทธิ์ขั้นต่ำสุดบน SLES 15 SP7 พร้อมหมายเหตุที่ชัดเจนเกี่ยวกับค่าเริ่มต้นของ SELinux ใน SLES 16

ใช้งาน SLES 15 STIG อย่างปลอดภัยด้วย OpenSCAP

ใช้งาน SLES 15 STIG อย่างปลอดภัยด้วย OpenSCAP

ใช้โปรไฟล์ STIG ที่ SUSE รองรับเพื่อสแกน SLES 15 ทดสอบการแก้ไข ตรวจสอบผลการค้นพบที่เหลือ และเก็บรักษาหลักฐานการประเมิน

กู้คืนการเข้าถึง Cockpit ไปยัง SUSE Linux Enterprise Server

กู้คืนการเข้าถึง Cockpit ไปยัง SUSE Linux Enterprise Server

ตรวจสอบหาสาเหตุของการเชื่อมต่อ Cockpit ที่ล้มเหลวผ่านทาง DNS, พอร์ต 9090, ซ็อกเก็ต systemd, firewalld, TLS และการตั้งค่าการเข้าสู่ระบบ โดยใช้คำแนะนำล่าสุดของ SUSE

กำหนดค่าการสลับใช้งานอีเธอร์เน็ตที่เชื่อถือได้ด้วย Bonding ใน SLES 15

กำหนดค่าการสลับใช้งานอีเธอร์เน็ตที่เชื่อถือได้ด้วย Bonding ใน SLES 15

สร้างการเชื่อมต่ออีเธอร์เน็ตสำรองบน ​​SLES 15 โดยใช้ YaST และ Wicked กำหนดค่าการเชื่อมต่อแบบแอคทีฟ-สำรอง และตรวจสอบพอร์ตทั้งสองและการสลับการทำงานเมื่อเกิดข้อผิดพลาด

สร้างโปรไฟล์ AutoYaST ที่สามารถนำกลับมาใช้ใหม่ได้สำหรับการติดตั้ง SLES 15

สร้างโปรไฟล์ AutoYaST ที่สามารถนำกลับมาใช้ใหม่ได้สำหรับการติดตั้ง SLES 15

แปลงระบบ SLES 15 ที่มีอยู่ให้เป็นโปรไฟล์ AutoYaST ที่ผ่านการตรวจสอบแล้ว ตรวจสอบความถูกต้อง และใช้โปรไฟล์ดังกล่าวในการติดตั้งเซิร์ฟเวอร์ทดสอบโดยใช้ขั้นตอนด้วยตนเองให้น้อยลง

การตั้งค่า KVM ใน SLES 15: กำหนดให้ VM ที่เลือกเริ่มต้นทำงานเมื่อบูตเครื่อง

การตั้งค่า KVM ใน SLES 15: กำหนดให้ VM ที่เลือกเริ่มต้นทำงานเมื่อบูตเครื่อง

ติดตั้งเครื่องมือ SLES 15 KVM และ libvirt เปิดใช้งานบริการโฮสต์ที่ถูกต้อง และกำหนดค่าเครื่องเสมือนที่เลือกให้เริ่มต้นทำงานหลังจากรีบูตเครื่อง

ทำการสำรองข้อมูล Nextcloud อย่างสม่ำเสมอโดยอัตโนมัติด้วย Restic และ Cron

ทำการสำรองข้อมูล Nextcloud อย่างสม่ำเสมอโดยอัตโนมัติด้วย Restic และ Cron

สำรองข้อมูลไฟล์ของ Nextcloud และ MariaDB ไปพร้อมกัน กำหนดเวลาสร้างสแนปช็อต Restic ที่เข้ารหัสด้วย cron และตรวจสอบการกู้คืนโดยไม่ต้องเสี่ยงต่อเซิร์ฟเวอร์ที่ใช้งานอยู่

สำรองข้อมูลและกู้คืนกล่องจดหมาย Zimbra CE โดยใช้การส่งออก TGZ

สำรองข้อมูลและกู้คืนกล่องจดหมาย Zimbra CE โดยใช้การส่งออก TGZ

ส่งออกกล่องจดหมาย Zimbra Community Edition ส่วนบุคคล ตรวจสอบความถูกต้องของการสำรองข้อมูล TGZ และกู้คืนรายการที่หายไปโดยไม่เขียนทับอีเมลที่มีอยู่