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
ภาพแสดงคำสั่งในเทอร์มินัลที่ใช้ตรวจสอบว่า AppArmor ทำงานอยู่ก่อนที่จะทำการสร้างโปรไฟล์
SUSE ระบุว่า AppArmor เปิดใช้งานโดยค่าเริ่มต้นในการติดตั้ง SLES 15 หากไม่มีเครื่องมือหรือรูปแบบ AppArmor แบบเต็ม ให้ติดตั้งรูปแบบด้วยคำสั่ง `pip install appArmor` sudo zypper in -t pattern apparmorหาก AppArmor ไม่ทำงาน ให้หาสาเหตุก่อนทำการโปรไฟล์ แทนที่จะสันนิษฐานว่าไฟล์โปรไฟล์เพียงอย่างเดียวให้การป้องกัน โปรไฟล์จะแนบอยู่กับเส้นทางของไฟล์ปฏิบัติการ การโปรไฟล์โปรแกรมห่อหุ้มในขณะที่เวิร์กโหลดจริงทำงานเป็นไบนารีอื่น อาจทำให้กระบวนการที่สำคัญไม่ถูกจำกัด
สร้างและปรับแต่งโปรไฟล์
เริ่มกระบวนการสร้างโปรไฟล์หยุดแอปพลิเคชันหากกำลังทำงานอยู่ จากนั้นเริ่มการสร้างโปรไฟล์:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
ภาพแสดงมุมมองเทอร์มินัลของ aa-genprof ขณะเริ่มต้นโปรไฟล์การเรียนรู้สำหรับไฟล์ปฏิบัติการตัวอย่าง
ชื่อบริการเป็นเพียงตัวอย่าง ให้ใช้ชื่อหน่วยจริง หรือละเว้นคำสั่งหยุดหากโปรแกรมไม่ได้ทำงานอยู่ คำสั่งนี้aa-genprofจะสร้างโปรไฟล์โดยประมาณเมื่อไม่มีอยู่ จากนั้นจะตั้งค่าให้อยู่ในโหมดแจ้งเตือน (เรียนรู้) โหลดใหม่ และทำเครื่องหมายในบันทึก โหมดแจ้งเตือนจะบันทึกคำขอที่อยู่นอกเหนือขอบเขตนโยบาย แต่จะอนุญาตให้ดำเนินการได้ นี่เป็นสถานะการเรียนรู้ชั่วคราว ไม่ใช่การบังคับใช้
ทดสอบพฤติกรรมการใช้งานจริงเปิดตัวสร้างโค้ดไว้ ในเทอร์มินัลอีกตัวหนึ่ง เริ่มบริการและเรียกใช้งานงานหรือฟีเจอร์ตัวอย่าง:
sudo systemctl start report-worker
sudo journalctl -f
ภาพแสดงมุมมองเทอร์มินัลประกอบการเริ่มต้นบริการตัวอย่างและติดตามการทำงานขณะที่บริการทำงานในโหมดการเรียนรู้
ครอบคลุมการเริ่มต้นทำงานตามปกติ เส้นทางการรับและส่งข้อมูลที่คาดหวัง งานที่กำหนดเวลาไว้ การจัดการข้อผิดพลาด และโปรแกรมช่วยเหลือใดๆ ที่แอปพลิเคชันเรียกใช้ โปรไฟล์สามารถเรียนรู้ได้เฉพาะคำขอที่สร้างขึ้นระหว่างการทดสอบเท่านั้น อย่าใช้เวิร์กโหลดที่ละเอียดอ่อนต่อการใช้งานจริงเพียงเพื่อสร้างเหตุการณ์ ควรใช้สภาพแวดล้อมการทดสอบที่ปลอดภัยและข้อมูลทดสอบที่เป็นตัวแทนจะดีกว่า
ตรวจสอบคำขอการเข้าถึงแต่ละรายการกลับไปที่aa-genprofและกดSเพื่อสแกนช่วงบันทึกที่ทำเครื่องหมายไว้ สำหรับทุกข้อความแจ้งเตือน ให้ตัดสินใจว่าแอปพลิเคชันต้องการไฟล์ ความสามารถ หรือการเปลี่ยนผ่านโปรแกรมย่อยนั้นจริงหรือไม่ อนุญาตเส้นทางและสิทธิ์ที่แคบที่สุดที่ใช้งานได้จริง ยอมรับนามธรรมเมื่อครอบคลุมงานทั่วไปได้อย่างถูกต้อง ใช้ glob เฉพาะเมื่อไฟล์ที่ตรงกันมีข้อกำหนดด้านความน่าเชื่อถือและการเข้าถึงเดียวกัน ปฏิเสธหรือข้ามคำขอที่ไม่เกี่ยวข้องหรือไม่สามารถอธิบายได้
ภาพแสดงมุมมองเทอร์มินัลของ aa-logprof เครื่องมือแบบโต้ตอบสำหรับตรวจสอบคำขอการเข้าถึงที่บันทึกไว้
ให้ความสำคัญเป็นพิเศษกับการดำเนินการคำขอ การเปลี่ยนสถานะที่ไม่จำกัดอาจทำให้กระบวนการลูกหลุดพ้นจากนโยบายของกระบวนการแม่ได้ ควรใช้เฉพาะเมื่อมีความจำเป็นในการออกแบบที่สมเหตุสมผลเท่านั้น ทำซ้ำขั้นตอนและรอบการสแกนหลังจากเพิ่มกฎที่ถูกต้อง เมื่อโปรไฟล์ครอบคลุมพฤติกรรมที่ทดสอบแล้ว ให้สิ้นสุดการสร้างโปรไฟล์ SUSE ระบุว่าการเสร็จสิ้นaa-genprofรอบการเรียนรู้ใหม่โดยปกติจะทำให้โปรไฟล์เข้าสู่โหมดบังคับใช้
ตรวจสอบนโยบายที่สร้างขึ้นสำหรับเส้นทางตัวอย่างนี้ ข้อกำหนดการตั้งชื่อของ SUSE จะแปลงเครื่องหมายทับในเส้นทางของไฟล์ปฏิบัติการเป็นจุด ทำให้ได้ผลลัพธ์เป็น/etc/apparmor.d/usr.local.bin.report-worker. ตรวจสอบผลลัพธ์แทนที่จะถือว่ากฎที่สร้างขึ้นนั้นปลอดภัยโดยอัตโนมัติ:
sudo less /etc/apparmor.d/usr.local.bin.report-worker
ภาพแสดงตัวอย่างการเปิดไฟล์โปรไฟล์ในเทอร์มินัล โดยชื่อไฟล์จะต้องตามหลังพาธของไฟล์ปฏิบัติการ
ตรวจสอบให้แน่ใจว่าชื่อโปรไฟล์ตรงกับไฟล์ปฏิบัติการที่ต้องการ ใช้ไฟล์ include ที่จำเป็น และให้สิทธิ์การเข้าถึงเฉพาะการกำหนดค่า ข้อมูล บันทึก การเชื่อมต่อ และโปรแกรมช่วยเหลือที่แอปพลิเคชันต้องการจริงๆ เท่านั้น หลีกเลี่ยงกฎกว้างๆ เช่น การให้สิทธิ์การเข้าถึงแบบไม่จำกัด/หรือการให้สิทธิ์การเข้าถึงทั้งโครงสร้างไฟล์ที่สามารถเขียนได้เพียงเพื่อปิดเสียงการปฏิเสธ แอปพลิเคชันยังคงขึ้นอยู่กับความเป็นเจ้าของและสิทธิ์การเข้าถึงแบบ Unix ทั่วไป AppArmor เพิ่มเลเยอร์การจำกัดเพิ่มเติมอีกชั้นหนึ่ง
ตั้งค่าโหมดที่ต้องการอย่างชัดเจนหลังจากตรวจสอบแล้ว ให้บังคับใช้โปรไฟล์สำหรับโปรแกรมที่กำหนดเอง:
sudo aa-enforce /usr/local/bin/report-worker
ภาพแสดงมุมมองเทอร์มินัลของคำสั่ง aa-enforce ที่ใช้ข้อจำกัดของโปรไฟล์กับโปรแกรมตัวอย่าง
หากคุณแก้ไขโปรไฟล์ด้วยตนเองหลังจากโปรแกรมสร้างโปรไฟล์ปิดตัวลงแล้ว ให้โหลดชุดโปรไฟล์ใหม่โดยใช้คำสั่ง ` sudo systemctl reload apparmorreload_profile_set` เอกสารของ SUSE อธิบายว่าการโหลดโปรไฟล์ใหม่เป็นการสแกนโปรไฟล์ซ้ำโดยไม่ต้องยกเลิกการจำกัดกระบวนการที่กำลังทำงานอยู่ จากนั้นรีสตาร์ทบริการแอปพลิเคชันเพื่อให้การตั้งค่าใหม่มีผลกับกระบวนการนั้น
ตรวจสอบใบสมัครภายใต้การบังคับใช้กฎหมาย
เรียกใช้งานงานที่เป็นตัวแทนเดิมอีกครั้งในขณะที่โปรไฟล์อยู่ในโหมดบังคับใช้ ตรวจสอบว่าบริการเริ่มต้น อ่านข้อมูลเข้าที่ต้องการ เขียนข้อมูลออกที่คาดหวัง และสามารถดำเนินการช่วยเหลือหรือการทำงานเครือข่ายที่จำเป็นได้ จากนั้นตรวจสอบทั้งสถานะของโปรไฟล์และข้อความเคอร์เนลล่าสุด:
sudo aa-status
sudo journalctl -k -g apparmor --since today
ภาพแสดงมุมมองเทอร์มินัลของการตรวจสอบสถานะที่ใช้เพื่อยืนยันว่าโปรไฟล์ที่กำหนดเองถูกโหลดในโหมดบังคับใช้แล้ว
ภาพแสดงมุมมองเทอร์มินัลประกอบการกรองบันทึกเคอร์เนลเพื่อค้นหาเหตุการณ์ AppArmor ระหว่างการตรวจสอบ
ไฟล์ปฏิบัติการที่กำหนดเองควรปรากฏเป็นสถานะโหลดและอยู่ในโหมดบังคับใช้ การปฏิเสธของ AppArmor ในบันทึกเคอร์เนลระบุคำขอที่นโยบายบล็อกไว้ ใช้ข้อมูลเหล่านี้เพื่อวินิจฉัยความล้มเหลวของแอปพลิเคชันจริง ไม่ใช่ใช้เป็นเหตุผลในการอนุญาตทุกเส้นทางที่บันทึกไว้ สำหรับกรณีที่ขาดสิทธิ์อย่างถูกต้อง ให้เรียกใช้sudo aa-logprofคำสั่ง ตรวจสอบคำแนะนำ อัปเดตกฎอย่างระมัดระวัง โหลดใหม่หากคุณแก้ไขด้วยตนเอง และเรียกใช้เส้นทางแอปพลิเคชันที่ได้รับผลกระทบอีกครั้ง
สำหรับบริการที่ทำงานอย่างต่อเนื่องซึ่งการสร้างโปรไฟล์ต้องครอบคลุมการรีบูตหรือการสังเกตการณ์ที่ยาวนานขึ้น SUSE ได้จัดทำเอกสารขั้นตอนการทำงานที่เป็นระบบแยกต่างหากโดยใช้aa-autodep, aa-complain, และaa-logprofการสแกนซ้ำ วิธีการแบบสแตนด์อะโลนaa-genprofนั้นง่ายกว่าเมื่อการเรียนรู้สามารถเปิดค้างไว้ได้ตลอดการทดสอบ ขั้นตอนการทำงานทั้งสองแบบไม่สามารถอนุมานพฤติกรรมของแอปพลิเคชันที่ไม่เคยถูกใช้งานได้ ดังนั้นควรตรวจสอบโปรไฟล์อย่างสม่ำเสมอเมื่อมีการเปลี่ยนแปลงซอฟต์แวร์หรือการกำหนดค่า
แหล่งที่มา