أعلنت SUSE عن إصدار SLES 16.0 في 4 نوفمبر 2025، حيث سيحل SELinux محل AppArmor كإطار عمل افتراضي للتحكم الإلزامي في الوصول. إذا كان خادمك يعمل بنظام SLES 16، فلا تفترض أن AppArmor مثبت أو مُفعّل: تأكد من إطار العمل المدعوم من قِبل هذا الإصدار قبل استخدام هذه الأوامر. يتبع الإجراء الموضح أدناه وثائق SUSE الخاصة بـ AppArmor لنظام 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
تُدرج SUSE ميزة AppArmor مُفعّلة افتراضيًا في أنظمة SLES 15. في حال عدم وجود الأدوات أو نمط AppArmor الكامل، يُرجى تثبيت النمط sudo zypper in -t pattern apparmor. إذا لم تكن AppArmor مُفعّلة، يُرجى تحديد السبب قبل إجراء تحليل الأداء، بدلًا من افتراض أن ملف تعريف الأداء وحده يوفر الحماية. يُرفق ملف تعريف الأداء بمسار ملف تنفيذي؛ لذا فإن تحليل أداء برنامج مُغلّف بينما يعمل عبء العمل الحقيقي كملف ثنائي آخر قد يُعرّض العملية المهمة للخطر.
ابدأ تشغيل المُولِّد. أوقف التطبيق إذا كان قيد التشغيل بالفعل، ثم ابدأ عملية إنشاء الملف الشخصي:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
اسم الخدمة مثال فقط. استخدم اسم الوحدة الحقيقي، أو احذف أمر الإيقاف إذا كان البرنامج غير قيد التشغيل. aa-genprofيقوم هذا الأمر بإنشاء ملف تعريف تقريبي في حال عدم وجوده، ويضعه في وضع "التعلم"، ثم يعيد تحميله، ويُعلّم السجل. يسجل وضع "التعلم" الطلبات المخالفة للسياسة ولكنه يسمح بها؛ فهو حالة تعلم مؤقتة، وليس تطبيقًا لها.
قم بتجربة سلوك التطبيق الحقيقي. أبقِ المُولِّد مفتوحًا. في نافذة طرفية أخرى، ابدأ الخدمة ونفِّذ مهامًا أو ميزات نموذجية:
sudo systemctl start report-worker
sudo journalctl -f
يشمل الاختبار بدء التشغيل العادي، ومسارات الإدخال والإخراج المتوقعة، والمهام المجدولة، ومعالجة الأخطاء، وأي برامج مساعدة يُشغلها التطبيق. لا يمكن للملف التعريفي إلا معرفة الطلبات التي يتم إنشاؤها أثناء الاختبار. تجنب استخدام أحمال العمل الحساسة للإنتاج لمجرد توليد الأحداث؛ يُفضل استخدام بيئة اختبار آمنة وبيانات اختبار تمثيلية.
راجع كل طلب وصول. ارجع إلى نطاق السجل المحدد aa-genprofواضغط Sلمسحه. لكل مطالبة، حدد ما إذا كان التطبيق يحتاج فعلاً إلى هذا الملف أو هذه الإمكانية أو عملية الانتقال بين البرامج الفرعية. اسمح بأضيق مسار وإذن مفيدين. اقبل التجريد عندما يغطي مهمة مشتركة بدقة؛ استخدم نمطًا عامًا فقط عندما تشترك الملفات المطابقة في نفس متطلبات الثقة والوصول. ارفض أو تخطَّ الطلبات العرضية أو غير المبررة.
انتبه جيدًا لطلبات التنفيذ. قد يسمح الانتقال غير المقيد لعنصر تابع بتجاوز سياسة العنصر الأصل؛ لذا استخدمه فقط عند وجود حاجة تصميمية مبررة. كرر العملية ودورة المسح بعد إضافة القواعد الصحيحة. عندما يغطي الملف التعريفي السلوك المختبر، أنهِ عملية التوليد. تشير SUSE إلى أن إكمال aa-genprofدورة تعلم جديدة عادةً ما يضع الملف التعريفي في وضع الإنفاذ.
افحص السياسة المُنشأة. في هذا المثال، يقوم نظام تسمية SUSE بتحويل الشرطات المائلة في مسار الملف التنفيذي إلى نقاط، مما ينتج عنه /etc/apparmor.d/usr.local.bin.report-worker. راجع النتيجة بدلاً من اعتبار القواعد المُنشأة آمنة تلقائيًا.
sudo less /etc/apparmor.d/usr.local.bin.report-worker
تأكد من أن اسم الملف التعريفي يُشير إلى الملف التنفيذي المطلوب، ويستخدم الملفات المضمنة اللازمة، ويمنح الوصول فقط إلى الإعدادات والبيانات والسجلات والمنافذ والبرامج المساعدة التي يحتاجها التطبيق فعليًا. تجنب القواعد العامة مثل منح وصول غير مقيد إلى /شجرة كاملة قابلة للكتابة لمجرد تجنب رفض الوصول. لا يزال التطبيق يعتمد على ملكية وأذونات نظام يونكس العادية؛ يُضيف AppArmor طبقة تقييد منفصلة.
حدد الوضع المطلوب صراحةً. بعد المراجعة، قم بتطبيق الملف التعريفي للبرنامج المخصص:
sudo aa-enforce /usr/local/bin/report-worker
إذا قمتَ بتعديل الملف الشخصي يدويًا بعد انتهاء المُولِّد، فأعد تحميل مجموعة الملفات الشخصية باستخدام الأمر المناسب sudo systemctl reload apparmor. تُعاد تحميل مستندات SUSE كملفات تعريفية لإعادة المسح دون إلغاء تقييد العمليات الجارية. أعد تشغيل خدمة التطبيق لتطبيق السياسة الجديدة على عمليتها.
أعد تشغيل نفس المهام التمثيلية أثناء تفعيل وضع التنفيذ في الملف التعريفي. تأكد من بدء تشغيل الخدمة، وقراءة مدخلاتها المقصودة، وكتابة مخرجاتها المتوقعة، وقدرتها على تنفيذ عمليات المساعدة أو الشبكة المطلوبة. ثم افحص حالة الملف التعريفي ورسائل النواة الأخيرة.
sudo aa-status
sudo journalctl -k -g apparmor --since today
يجب أن يظهر الملف التنفيذي المخصص مُحمّلاً وفي وضع الإنفاذ. تُحدد حالات رفض AppArmor في سجل النواة الطلبات التي حظرتها السياسة؛ استخدمها لتشخيص عطل حقيقي في التطبيق، وليس كمبرر للسماح بكل مسار مُسجّل. في حالة وجود إذن مفقود مشروع، شغّل الأمر sudo aa-logprof، راجع الاقتراح، حدّث القاعدة بشكل محدود، أعد التحميل إذا عدّلتها يدويًا، ثم أعد تشغيل مسار التطبيق المتأثر.
بالنسبة للخدمات التي تعمل باستمرار والتي يتطلب تحليل أدائها عمليات إعادة تشغيل أو مراقبة طويلة الأمد، توثق SUSE سير عمل نظاميًا منفصلاً باستخدام aa-autodepعمليات مسح aa-complainمتكررة aa-logprof. تُعدّ الطريقة المستقلة aa-genprofأبسط عندما يمكن إبقاء عملية التعلم مفتوحة طوال فترة الاختبار. لا يمكن لأي من سيرَي العمل استنتاج سلوك التطبيق الذي لم يتم اختباره مسبقًا، لذا يُنصح بمراجعة ملف تعريف الأداء عند إجراء أي تغييرات على البرامج أو الإعدادات.
يمكن ترقية نظام SLES 15 SP5 إلى SP6 عبر الإنترنت، ولكن يجب إعادة تشغيل كل عقدة. استخدم ترقية متدرجة مُختبرة أو عملية نقل تدريجية (أزرق-أخضر) للحفاظ على إمكانية الوصول إلى أحمال العمل.
قم بإنشاء وتحسين والتحقق من ملف تعريف AppArmor ذي أقل الامتيازات على SLES 15 SP7، مع ملاحظة واضحة حول SELinux الافتراضي في SLES 16.
استخدم ملف تعريف STIG المدعوم من SUSE لفحص SLES 15، واختبار المعالجة، ومراجعة النتائج المتبقية، والاحتفاظ بأدلة التقييم.
تتبع فشل اتصال Cockpit من خلال DNS، والمنفذ 9090، ومقبس systemd، وfirewalld، وTLS، وإعدادات تسجيل الدخول باستخدام إرشادات SUSE الحالية.
قم بإنشاء اتصال إيثرنت زائد على SLES 15 باستخدام YaST و Wicked، وقم بتكوين ربط النسخ الاحتياطي النشط، وتحقق من كلا المنفذين والتحويل التلقائي في حالة الفشل.
قم بتحويل نظام SLES 15 الحالي إلى ملف تعريف AutoYaST تمت مراجعته، وقم بالتحقق من صحته، واستخدمه لنشر خادم اختبار بخطوات يدوية أقل.
قم بتثبيت أدوات SLES 15 KVM و libvirt، وقم بتمكين خدمة المضيف الصحيحة، وقم بتكوين الأجهزة الافتراضية المحددة للبدء بعد إعادة التشغيل.
استخدم وظائف systemd وسجل التمهيد السابق لتحديد موقع خدمة بطيئة أو عملية تحميل أو تبعية تخزين، ثم قم بتصحيحها دون إخفاء السبب.
استخدم firewall-cmd لفحص المنطقة النشطة، والسماح بـ HTTP بأمان، والحفاظ على الوصول إلى SSH، والتحقق من أن القاعدة تبقى بعد إعادة التحميل على SLES 15.
تتبع فشل PAM إلى الخدمة أو سياسة الحساب أو موفر الهوية، ثم قم بإصلاح تكوين SLES الصحيح مع الحفاظ على جلسة مسؤول عاملة.
