تقوية وحدات systemd 2026: دليل عزل الخدمات (Sandboxing) وتقليل نطاق الاختراق على لينكس

آخر تحديث: 9 يوليو 2026

تقوية وحدات systemd هي عملية تقليص صلاحيات كل خدمة إلى الحد الأدنى الذي تحتاجه فعليًا للعمل، باستخدام أكثر من ثلاثين توجيهًا مدمجًا في systemd.exec مثل ProtectSystem وCapabilityBoundingSet وSystemCallFilter، بحيث لا يمنح الاختراق المحتمل للمهاجم إلا الجزء الضروري من النظام. سنبني في هذا الدليل نموذج تهديد واقعيًا، ثم نطبّق طبقات العزل واحدة تلو الأخرى، ونقيس النتيجة عبر systemd-analyze security. الهدف بسيط: خدمة إذا سقطت، لا تسقط معها الآلة كلها.

• ملف الوحدة الافتراضي الذي يشحنه المشغِّل مع الحزم يعمل دون أي عزل تقريبًا؛ درجة systemd-analyze security له عادةً ≥ 9.0 من 10 (UNSAFE).
• الرباعي الأساسي الذي يخفض الدرجة أكثر من نصف نقطة لكل توجيه هو: NoNewPrivileges=yes، ProtectSystem=strict، PrivateTmp=yes، وCapabilityBoundingSet ضيّق.
• SystemCallFilter=@system-service يُغلق مباشرةً استدعاءات mount وreboot وmodule_load؛ يجب دائمًا اقترانه بـ SystemCallArchitectures=native.
• لا تُعدِّل ملف الوحدة الأصلي أبدًا؛ استخدم systemctl edit لإنشاء drop-in override في /etc/systemd/system/<name>.service.d/override.conf.
• خطوة الاختبار مفروضة: بعد كل توجيه، راجع journalctl -u <name> -p err، فأغلب حالات الكسر تظهر كأخطاء EPERM أو Read-only file system.
• ضع في اعتبارك أن الدرجة إشارة استرشادية وليست إثبات أمان؛ SELinux/AppArmor يبقيان طبقة ضرورية إلى جانب توجيهات systemd.

ما هي تقوية وحدات systemd ولماذا تهم في 2026؟

تقوية وحدات systemd (systemd unit hardening)، أو ما يُشار إليه أحيانًا بـ service sandboxing، هي مجموعة توجيهات تُضاف إلى قسم [Service] في ملف الوحدة، وتُطبَّق من قِبَل PID 1 عند إطلاق الخدمة كل مرة. هذه التوجيهات ليست مكوّنًا خارجيًا يجب تثبيته، بل هي جزء من نواة systemd نفسها منذ الإصدار 232، وتوسّعت بشكل كبير حتى الإصدار الحالي 256 المتوفر افتراضيًا على Fedora 41 وUbuntu 26.04.

السبب المباشر لأهميتها: أغلب ملفات الوحدة التي تشحنها الحزم (من nginx إلى PostgreSQL إلى تطبيقك الداخلي بلغة Go) لا تُفعّل أيًا من هذه التوجيهات. النتيجة أن خدمة ويب صغيرة تعمل بصلاحيات كاملة على نظام الملفات، ترى كل عمليات المضيف عبر /proc، تستطيع تحميل وحدات نواة، وتفتح مآخذ خام على أي عائلة عناوين. اختراق واحد لتلك الخدمة يمنح المهاجم كل هذه القوة الكامنة دون قيد.

في 2026 صار هذا الوضع غير مقبول عمليًا لعدّة أسباب: (1) توسّع سطح الهجوم عبر استدعاءات النظام الجديدة مثل io_uring التي تُستغل في هروب الحاويات، (2) التزامات الامتثال (CIS Benchmark for Linux 2026 v2) التي تُدرج ضمن ضوابطها فحص درجة systemd-analyze security، و(3) نضج أدوات القياس بحيث لم تعد التقوية عملية تخمين. للحصول على طبقة إلزام إضافية بجانب هذه التوجيهات، راجع دليلنا حول تقوية SELinux على RHEL وRocky وAlmaLinux؛ فطبقة MAC تعمل بشكل تكاملي مع sandbox الخاص بـ systemd.

نموذج التهديد: ماذا يكسر أولًا عند الاختراق؟

قبل كتابة توجيه واحد، ارسم في ذهنك المخطط التالي: خدمتك عبارة عن عملية تجلس داخل صندوق. جدران هذا الصندوق سبعة: نظام الملفات، الشبكة، الفضاءات (namespaces)، الصلاحيات (capabilities)، استدعاءات النظام، الذاكرة، وIPC (SysV/POSIX). كل جدار مكسور يعني مسارًا يستطيع المهاجم عبوره بعد اختراق أول للخدمة (RCE عبر ثغرة، أو تنفيذ عبر حمولة deserialization).

سؤالنا الأساسي كمعماريين: ماذا يكسر أولًا؟ الجواب في معظم الحوادث الواقعية التي عايشتها هو الجدار الأول والأرخص، وهو الكتابة في نظام الملفات. المهاجم يُسقط ثنائيًا في /tmp، يبدّل سكربت cron في /etc/cron.d، أو يعبث بمكتبة في /usr/lib. بعدها مباشرةً، الجدار الثاني الذي يسقط هو رفع الصلاحيات عبر ثنائي setuid داخل النظام. الجدار الثالث والأخطر: قدرة العملية على استدعاء ptrace أو init_module فتصبح جزءًا من النواة نفسها.

خريطة نطاق الاختراق (blast radius) هذه هي ما توجّه ترتيب التقوية: نبدأ بالجدارَين الأرخصَين (نظام الملفات، NoNewPrivileges)، ثم نضيف قيود Capabilities، ثم seccomp. هذا الترتيب ليس تجميليًا، بل هو ترتيب التغطية: كل طبقة تُحيّد فئة كاملة من CVE مستقبلية لا تعرف عنها الآن شيئًا.

كيف تفحص درجة أمان خدمة systemd؟

الأداة الأولى هي systemd-analyze security. تُصدر جدولًا مفصّلًا يحوي كل توجيه معروف، القيمة الحالية، الوزن المُخصّص له، وفي الأسفل درجة الانكشاف الإجمالية من 0.0 إلى 10.0 مع حكم نصّي (OK، MEDIUM، EXPOSED، UNSAFE). القاعدة العملية التي أعمل بها: أي شيء فوق 7.0 يحتاج عملًا فوريًا، ودون 3.0 يعني تقوية جيدة جدًا.

# البدء بقياس الوضع الحالي قبل أي تعديل
systemd-analyze security nginx.service

# قراءة موجزة لجميع الوحدات المُشغَّلة
systemd-analyze security --no-pager | sort -k2 -h

# عرض التفاصيل لتوجيه محدد فقط
systemd-analyze security nginx.service --json=pretty | jq '.[] | select(.name=="ProtectSystem")'

الأعمدة التي يجب مراقبتها في الجدول: Exposure (وزن التوجيه)، Predicate (شرح مبسّط)، وHappy (علامة ✓ أو ✗ إن كان التوجيه في وضع آمن). كل صف مكتوب بالأحمر هو بند في قائمة أعمالك. ابدأ من التوجيهات ذات الوزن الأعلى (0.5+) لأن كل واحد منها ينقل الدرجة نصف نقطة أو أكثر.

عزل نظام الملفات: ProtectSystem وReadWritePaths

هذه هي الطبقة الأرخص والأعلى أثرًا. ثلاثة توجيهات تعمل معًا: ProtectSystem يجعل /usr و/boot (وفي وضع strict يضاف /etc) للقراءة فقط. ProtectHome يخفي /home و/root و/run/user كليًا عن العملية. ثم ReadWritePaths يفتح ثقوبًا محدّدة للكتابة حيث تحتاجها الخدمة فعليًا (سجلاتها، قاعدة بياناتها).

# /etc/systemd/system/nginx.service.d/override.conf
[Service]
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/log/nginx /var/cache/nginx /run/nginx

ثلاثة مبادئ عملية: أولًا، جرّب ProtectSystem=full قبل strict إذا لم تكن الخدمة معروفة لديك جيدًا؛ الفرق أن strict يجعل /etc للقراءة فقط أيضًا وقد يكسر خدمات تُحدِّث ملفات إعداد في وقت التشغيل. ثانيًا، PrivateTmp=yes يعطي الخدمة مساحة /tmp منعزلة عبر mount namespace، فتغلق مباشرةً فئة كاملة من هجمات symlink race. ثالثًا، ReadWritePaths تقبل أنماطًا وليس ملفات فقط، لكنها لا تتّبع الروابط الرمزية عبر gaps؛ استخدم المسار الحقيقي.

هناك مجموعة توجيهات كتلة كبيرة تعمل بلا كسر تقريبًا لأي خدمة عادية:

[Service]
ProtectKernelTunables=yes     # يمنع الكتابة في /proc/sys و/sys
ProtectKernelModules=yes      # يمنع تحميل/إزالة وحدات النواة
ProtectKernelLogs=yes         # يمنع قراءة dmesg
ProtectControlGroups=yes      # /sys/fs/cgroup للقراءة فقط
ProtectClock=yes              # يمنع ضبط ساعة النظام
ProtectHostname=yes           # يمنع تغيير اسم المضيف
ProtectProc=invisible         # الخدمة لا ترى إلا عملياتها في /proc
ProcSubset=pid                # /proc/sys وغيره مخفي عن الخدمة

تقييد صلاحيات الجذر عبر CapabilityBoundingSet

لينكس فكّك صلاحيات root إلى ~40 قدرة (capability) مستقلة منذ نواة 2.2. توجيه CapabilityBoundingSet هو السقف الأعلى — بعد تطبيقه لا تستطيع العملية اكتساب أي قدرة خارج القائمة، حتى لو حاولت التلاعب عبر setuid. AmbientCapabilities يُكمل ذلك بتحديد ما تبدأ به العملية فعليًا.

القاعدة الأمثل: ابدأ من مجموعة فارغة، شغّل الخدمة، اقرأ الأخطاء في journalctl، وأضِف قدرة واحدة فقط لكل خطأ. لخدمات الويب النموذجية، القدرة الوحيدة المطلوبة عادةً هي CAP_NET_BIND_SERVICE للاستماع على المنافذ دون 1024.

[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=yes

ثلاث قدرات يجب عليك التخلص منها في كل خدمة تقريبًا لأنها بوابات لكارثة عند الاختراق: CAP_SYS_ADMIN (شبه-root، تُتيح mount وrename وغيره)، CAP_SYS_MODULE (تحميل وحدات النواة = هروب فوري)، وCAP_SYS_PTRACE (قراءة ذاكرة عمليات أخرى). التوجيه NoNewPrivileges=yes ضروري لأنه يمنع أي ثنائي setuid داخل الخدمة من رفع الصلاحيات لاحقًا، بل ويُلزم seccomp بحيث لا يمكن تجاوزه من داخل العملية نفسها.

تصفية استدعاءات النظام (SystemCallFilter وseccomp)

هذه هي الطبقة الأعمق. seccomp (عبر SystemCallFilter) يمنع النواة نفسها من تنفيذ استدعاءات محددة حتى لو نجح المهاجم في الوصول لعملية الخدمة. systemd يقدّم مجموعات معرّفة مسبقًا (تبدأ بـ @) تُغني عن سرد مئات الاستدعاءات يدويًا.

[Service]
# اسمح فقط بمجموعة "خدمة نظام" المعتادة
SystemCallFilter=@system-service
# اطرح مجموعات خطرة صراحةً
SystemCallFilter=~@debug @mount @swap @reboot @privileged @resources @cpu-emulation @obsolete
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native

ثلاث ملاحظات دقيقة يقع فيها كثيرون: (1) الترتيب مهم — القاعدة الأخيرة تربح، لذا نبدأ بـ allow-list ثم نطرح ما نريد إزالته. (2) SystemCallArchitectures=native يمنع خدعة قديمة يستخدمها المهاجمون بتبديل ABI (مثل استدعاء 32-bit من عملية 64-bit) لتجاوز الفلتر. (3) SystemCallErrorNumber=EPERM يجعل الاستدعاءات المرفوضة تُرجِع خطأً بدل إنهاء العملية، وهذا أخفّ على التطبيقات التي تجرّب استدعاءات اختيارية.

لخدمات معيّنة قد تحتاج مجموعات إضافية: @network-io لخوادم الشبكة، @file-system للخدمات التي تنشئ ملفات بكثرة، @process للخدمات التي تُنجب عمليات ابنة (مثل CI runners). راجع دليل systemd.exec الرسمي للقائمة الكاملة للمجموعات وأوزانها.

تقييد الشبكة والفضاءات (Namespaces)

حتى بعد إغلاق نظام الملفات والقدرات، تبقى الشبكة سطحًا واسعًا. RestrictAddressFamilies يقصر الخدمة على عائلات محددة من مآخذ الشبكة؛ خدمة ويب لا تحتاج إلا AF_INET AF_INET6 AF_UNIX. حظر AF_NETLINK يقطع طريقًا شائعًا لاستكشاف بيئة الاختراق.

[Service]
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
IPAddressDeny=any
IPAddressAllow=localhost
IPAddressAllow=10.0.0.0/8
RestrictNamespaces=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
RemoveIPC=yes
PrivateUsers=yes

ثلاث قنابل يدوية شائعة أوقفت لديّ عدة سلاسل استغلال فعلية: MemoryDenyWriteExecute=yes يمنع كتابة صفحة ذاكرة قابلة للتنفيذ في آن واحد، فيُبطل shellcode التقليدي. LockPersonality=yes يمنع تبديل ABI (مثل تفعيل PER_LINUX32) لتفادي قيود seccomp. PrivateUsers=yes يضع الخدمة داخل user namespace خاص، فحتى لو تحوّلت لـ UID 0 بداخله فهي عديمة الصلاحيات في نمط UIDs المضيف.

لتقييد الوصول الشبكي بشكل أدق، IPAddressDeny=any ثم IPAddressAllow بالمقاطع المسموح بها تُنشئ جدار حماية على مستوى الوحدة عبر eBPF داخل النواة. هذا مفيد للخدمات التي يجب ألا تخرج إلى الإنترنت أبدًا (مثل عامل قاعدة بيانات داخلي). للربط مع طبقة أعمق، راجع دليلنا حول كتابة ملفات تعريف AppArmor على Ubuntu وDebian؛ الجمع بين توجيهات systemd وملف تعريف MAC يقترب من الحاوية دون تعقيدها.

مثال كامل: تقوية خدمة nginx خطوة بخطوة

لنطبّق كل ما سبق على nginx كخدمة نموذجية. الوحدة الافتراضية التي تُثبّتها الحزمة على Ubuntu 26.04 تحصل على درجة 9.6 UNSAFE. الهدف: النزول إلى ما دون 2.5 OK دون كسر الخدمة.

الخطوة 1. إنشاء override وليس تعديل الملف الأصلي:

sudo systemctl edit nginx.service
# يفتح المحرر على ملف فارغ في:
# /etc/systemd/system/nginx.service.d/override.conf

الخطوة 2. لصق التوجيهات على شكل طبقات مرقّمة:

[Service]
# طبقة 1: نظام الملفات
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ReadWritePaths=/var/log/nginx /var/cache/nginx /var/lib/nginx /run

# طبقة 2: النواة والوقت
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
ProtectControlGroups=yes
ProtectClock=yes
ProtectHostname=yes
ProtectProc=invisible
ProcSubset=pid

# طبقة 3: القدرات والامتيازات
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_CHOWN CAP_SETUID CAP_SETGID CAP_DAC_OVERRIDE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=yes
RestrictSUIDSGID=yes

# طبقة 4: الشبكة والفضاءات
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
RestrictNamespaces=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RemoveIPC=yes

# طبقة 5: تصفية استدعاءات النظام
SystemCallFilter=@system-service
SystemCallFilter=~@debug @mount @swap @reboot @privileged @cpu-emulation @obsolete
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native

الخطوة 3. التطبيق والقياس:

sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemd-analyze security nginx.service
# متوقع: Overall exposure level ≈ 2.1 OK

# إذا كسرت الخدمة، ابحث عن السبب:
sudo journalctl -u nginx -p err --since "5 minutes ago"

ملاحظتان من الميدان: (أ) أبقيت CAP_CHOWN CAP_SETUID CAP_SETGID CAP_DAC_OVERRIDE لأن nginx يبدأ كـ root ثم يُسقط إلى worker غير مميّز؛ إزالة أيٍّ منها ستمنع بدء التشغيل. (ب) AF_NETLINK ضروري لبعض إصدارات nginx التي تراقب تغيّرات واجهات الشبكة؛ إزالته تُنتج تحذيرات في السجل لكنها ليست قاتلة.

DynamicUser والمستخدمون الديناميكيون

DynamicUser=yes ميزة من أذكى ما قدّمه systemd منذ سنوات، بصراحة. عند التفعيل، ينشئ systemd مستخدمًا ومجموعة مؤقتَين بـ UID/GID عشوائيَين لكل تشغيل، ثم يمحوهما عند التوقف. لا يبقى للمهاجم حساب دائم يستهدفه في /etc/passwd، ولا ملفات ملوّثة يعثر عليها المشرف لاحقًا في نقاط find / -uid.

[Service]
DynamicUser=yes
StateDirectory=myapp
CacheDirectory=myapp
LogsDirectory=myapp
RuntimeDirectory=myapp

ثلاث فوائد تراكمية: (1) تلقائيًا يُفعّل PrivateTmp وProtectSystem=strict وProtectHome=yes وPrivateDevices وProtectClock وغيرها، (2) توجيهات StateDirectory/LogsDirectory/CacheDirectory تنشئ أدلة تحت /var/lib//var/log//var/cache بملكية المستخدم الديناميكي وتُضاف تلقائيًا إلى ReadWritePaths، (3) عند إزالة الخدمة، الأدلة تبقى وتُعاد نسبتها للمستخدم الجديد في المرة التالية دون تدخّل. عيبها الوحيد: لا يعمل مع خدمات تحتاج UID ثابتًا للتوافق مع بيانات موجودة (مثل خادم قاعدة بيانات قائم منذ فترة).

كيف تختبر أن التقوية لم تكسر الخدمة؟

الاختبار جزء لا يتجزأ من عملية التقوية، وليس خطوة اختيارية. الأخطاء الشائعة تظهر في أربعة أنماط: EPERM من فلتر seccomp، Read-only file system من ProtectSystem، Operation not permitted من CapabilityBoundingSet، وFailed to create /tmp/... من PrivateTmp عند خدمات تعتمد على /tmp مشتركة.

# 1) مراقبة أخطاء بدء الخدمة مباشرةً
sudo journalctl -u nginx -f -p err

# 2) اختبار سلوكي (smoke test) بعد كل تعديل
curl -sSf http://localhost/ >/dev/null && echo "OK" || echo "FAIL"

# 3) قياس تأثير الأداء
systemd-cgtop -m -n5 | grep nginx

# 4) في الإنتاج: نشر التقوية عبر staging أولاً
# وابحث في السجل عن رسائل seccomp:
sudo journalctl -k | grep -i "seccomp\|audit"

نصيحة معمارية من تجربتي: طبّق التقوية على مراحل، لا دُفعة واحدة. المرحلة الأولى (نظام الملفات + NoNewPrivileges) نادرًا ما تكسر شيئًا. المرحلة الثانية (CapabilityBoundingSet + PrivateNetwork) تحتاج تجربة على نسخة staging. المرحلة الثالثة (SystemCallFilter بمجموعات محدّدة) تحتاج بيئة اختبار حمل حقيقية لأن بعض الاستدعاءات النادرة لا تظهر إلا تحت ضغط. بعد كل مرحلة، أعد systemd-analyze security وتحقق أن الدرجة تنخفض دون كسر الوظيفة.

الأخطاء الشائعة عند تقوية systemd

خمسة أخطاء متكررة رأيتها في مراجعات معمارية أُجريها للفرق:

1. تعديل ملف الوحدة الأصلي في /lib/systemd/system/. سيُكتب فوقه عند الترقية القادمة وتختفي كل تقويتك بصمت. استخدم دائمًا systemctl edit.
2. تفعيل PrivateNetwork=yes لخدمة شبكة. يبدو للوهلة الأولى نصرًا أمنيًا، لكنه يفصل الخدمة عن كل الشبكة بما في ذلك المنافذ التي يجب أن تستمع عليها.
3. الاعتماد على الدرجة كإثبات أمان. الدرجة تقيس وجود التوجيه، لا صحّة قيمه. ReadWritePaths=/ يعطي علامة "مُعدّ" لكنه لا يعزل شيئًا.
4. حذف كل القدرات دون فحص. بعض التطبيقات تحتاج CAP_SYS_RESOURCE لضبط ulimit، أو CAP_KILL لإدارة العمال. القراءة أولًا، ثم الحذف.
5. إهمال طبقة MAC. توجيهات systemd تُقلّل نطاق الاختراق لكنها لا تُلزم سياسة نوعية على مستوى الملفات. اجمعها مع SELinux أو AppArmor، وحصّن قناة الوصول عبر تأمين SSH بمفاتيح Ed25519 وFIDO2.

مورد مرجعي إضافي لبناء نموذجك التهديدي: صفحة ArchWiki حول systemd/Sandboxing تحوي مصفوفة كاملة بين كل توجيه وفئة التهديد التي يُغطّيها، وهي مرجعي الشخصي عند مراجعة وحدات جديدة.

أسئلة شائعة

ما الفرق بين ProtectSystem=full و strict و read-only؟

read-only يجعل النظام بأكمله للقراءة عدا /dev و/proc و/sys. full يضيف /etc للاستثناء (يبقى قابلًا للكتابة). strict هو الأشدّ ويجعل كل نظام الملفات للقراءة فقط، ثم تفتح أدلة الكتابة الضرورية عبر ReadWritePaths. للخدمات الجديدة ابدأ بـ full، ثم انتقل إلى strict بعد تحديد أدلة الكتابة كلها.

هل تؤثر تقوية systemd على أداء الخدمة؟

الأثر عمليًا مهمل لأغلب التوجيهات؛ ProtectSystem وCapability* لا تكلفة جري لهما. SystemCallFilter يُضيف فحصًا لكل استدعاء لكنه ينفَّذ في النواة كـ BPF مُجمَّع، ويقاس بأقل من 1% في معظم أحمال العمل. الاستثناء الوحيد هو IPAddressAllow/Deny على أحمال شبكية عالية جدًا، ويُنصح فيها بجدار حماية على مستوى الشبكة بدل توجيه الوحدة.

هل يمكن استخدام DynamicUser مع قاعدة بيانات قائمة؟

لا يُنصح به. DynamicUser يمنح UID عشوائيًا في كل تشغيل، فإذا احتوت بيانات قاعدتك على ملفات مملوكة لـ UID محدّد ستكسر الخدمة أو تفقد صلاحيات القراءة. استخدم مستخدمًا ثابتًا (User=postgres) لخدمات ذات حالة مستمرة، واحفظ DynamicUser لخدمات عديمة الحالة كخوادم HTTP بسيطة أو عمّال معالجة قصيرة العمر.

كيف أطبّق التقوية على وحدات كثيرة عبر أسطول خوادم؟

ابنِ ملف drop-in واحدًا كـ baseline (مثلاً /etc/systemd/system/hardening-baseline.conf.d/00-baseline.conf) ثم اربطه لكل وحدة عبر Ansible/Salt/Puppet. أنشئ tests دورية تُشغّل systemd-analyze security على قائمة الخدمات المستهدفة وتفشل إذا تجاوزت الدرجة عتبة معيّنة. أدوات مثل Sysdig وAqua تُقدّم تقارير امتثال تلقائية على مستوى الأسطول.

هل توجيهات systemd تُغني عن SELinux أو AppArmor؟

لا. توجيهات systemd تعمل على مستوى العملية (DAC + namespaces + seccomp)، أما SELinux وAppArmor فيعملان على مستوى MAC (mandatory access control) بسياسة مركزية على مستوى الملفات والملصقات. الطبقات مكمّلة: تقوية systemd تمنع الخدمة من فعل ما لا تحتاجه، بينما MAC يمنع أي عملية على النظام (بما فيها root) من الوصول لملفات خارج نطاقها المصنّف. المستوى المؤسسي يشغّل الطبقتَين معًا.