devstuff/harden-docker-seccompتخفيف Docker لثغرة CVE-2026-31431 ('فشل النسخ'). يتضمن قوالب Kubernetes أيضًا.
نص برمجي ذو حالة ثابتة (Idempotent) لحظر إنشاء مقبس AF_ALG لجميع حاويات Docker
على المضيف كإجراء تخفيفي لثغرة CVE-2026-31431 ("Copy Fail").
CVE-2026-31431 هي ثغرة تصعيد صلاحيات محلية في قالب التشفير authencesn في نواة لينكس،
موجودة في النوى المبنية بين عام 2017 وتوفر الإصلاح الرسمي (الالتزام الرئيسي a664bf3d603d).
يمكن لمستخدم غير مميز ربط عملية مقبس AF_ALG مع splice() لتنفيذ كتابة محكومة من 4 بايت
في ذاكرة التخزين المؤقت للصفحات لأي ملف قابل للقراءة، مستهدفًا ملف setuid للحصول على
صدفة جذر. إثبات مفهوم بلغة بايثون بحجم 732 بايت يستغل هذه الثغرة بشكل موثوق،
بدون سباقات أو إزاحات خاصة بالتوزيعات، على كل توزيعات لينكس الرئيسية التي تشحن نواة متأثرة.
الخطوة الأولى الإلزامية للاستغلال هي فتح مقبس AF_ALG
(socket(AF_ALG, SOCK_SEQPACKET, 0)). حظر استدعاء النظام هذا عبر seccomp
يمنع الاستغلال حتى على النوى غير المصححة. ملف تعريف seccomp الافتراضي المدمج في Docker
لا يحظر ، و غير كافٍ — أظهرت المجموعات المختبرة أن الحاويات
المقبولة تحت PSS Restricted لا تزال قادرة على فتح مقابس .
AF_ALGRuntimeDefaultAF_ALGراجع إشعار الباحث الأصلي على https://copy.fail وإشعار CERT-EU على https://cert.europa.eu/publications/security-advisories/2026-005/ للحصول على التفاصيل التقنية الكاملة وتوفر التصحيحات حسب التوزيعة.
يغطي هذا النص البرمجي التكوين العام لخادم Docker Engine. بالنسبة
لـ Kubernetes، راجع قسم Kubernetes أدناه. بالنسبة لأحمال العمل
على الأجهزة الفعلية أو الأجهزة الافتراضية (غير المحتواة)، قم بتعطيل وحدة النواة algif_aead بدلاً من ذلك:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
هذا النهج ليس له أي تأثير على dm-crypt/LUKS أو kTLS أو IPsec/XFRM أو OpenSSL أو GnuTLS أو NSS أو SSH.
يستخرج ملف تعريف seccomp الافتراضي النشط لـ Docker عن طريق فحص
HostConfig.SecurityOpt لحاوية قصيرة العمر. هذا يتجنب أي اعتماد على
عنوان URL بعيد ويضمن أن ملف التعريف الأساسي يطابق إصدار Docker المثبت فعليًا.
يتم استخدام جلب من GitHub من
moby/profiles كخيار احتياطي
فقط إذا لم ينتج فحص الحاوية أي شيء.
يصحح ملف التعريف عن طريق إزالة socket من قائمة السماح في Docker
وإعادة إضافته مع مرشح وسائط يسمح بجميع عائلات العناوين
باستثناء AF_ALG (القيمة 38) باستخدام SCMP_CMP_NE. جميع سلوكيات
seccomp الافتراضية الأخرى في Docker محفوظة.
يكتب ملف التعريف المصحح بشكل ذري إلى
/etc/seccomp/docker-block-af-alg.json (ملف مؤقت + إعادة تسمية). يتم تخطيه إذا
كان محتوى الملف على القرص مطابقًا بالفعل.
يحدّث /etc/docker/daemon.json لتعيين "seccomp-profile" إلى
مسار ملف التعريف المصحح. يتم نسخ الملف الأصلي احتياطيًا إلى daemon.json.bak
عند أول تعديل. يتم تخطيه إذا كان مكوّنًا بشكل صحيح بالفعل.
يعيد تحميل dockerd عبر systemctl reload docker (SIGHUP — لا حاجة لإعادة تشغيل).
يتم تخطيه إذا لم يتغير أي ملف.
يتحقق من أن الحظر نشط عن طريق تشغيل فحص داخل حاوية، بغض النظر عن إجراء أي تغييرات في الخطوات أعلاه.
النص البرمجي ذو حالة ثابتة: تشغيله عدة مرات ينتج نفس النتيجة ويعيد تحميل Docker فقط عندما يتغير شيء فعليًا.
ملاحظة: حاويات
--privilegedتتجاوز جميع ملفات تعريف seccomp بغض النظر عن هذا التكوين. قم بمراجعة ملفات Compose وأوامر التشغيل الخاصة بك للحاويات المميزة بشكل منفصل.
docker في PATHcurl في PATH (خيار احتياطي فقط)systemctl (مضيف systemd)/etc/seccomp و/etc/docker، ولـ
systemctl reload docker# تطبيق الإجراء التخفيفي والتحقق (الاستخدام العادي)
sudo python3 harden-docker-seccomp.py
# عرض ما سيتغير دون كتابة أي شيء أو إعادة تحميل Docker
sudo python3 harden-docker-seccomp.py --dry-run
# إعادة تشغيل التحقق من الحاوية فقط (بدون تغييرات في التكوين)
python3 harden-docker-seccomp.py --verify-only
# إخراج تفصيلي
sudo python3 harden-docker-seccomp.py --verbose
INFO Written: /etc/seccomp/docker-block-af-alg.json
INFO Updated: /etc/docker/daemon.json
INFO Reloading Docker daemon (SIGHUP)…
INFO Docker daemon reloaded.
INFO Verifying AF_ALG is blocked inside a container…
OK: AF_ALG blocked — [Errno 1] Operation not permitted
INFO All done. CVE-2026-31431 (Copy Fail) mitigation is active.
INFO Profile unchanged: /etc/seccomp/docker-block-af-alg.json
INFO daemon.json already configured correctly.
INFO No changes — Docker daemon reload not required.
INFO Verifying AF_ALG is blocked inside a container…
OK: AF_ALG blocked — [Errno 1] Operation not permitted
INFO All done. CVE-2026-31431 (Copy Fail) mitigation is active.
| الرمز | المعنى |
|---|---|
0 | نجاح — الإجراء التخفيفي نشط |
1 | النص البرمجي لم يُشغَّل بصلاحيات الجذر (عند التصحيح)، أو خطأ غير قابل للاسترداد |
2 | فشل التحقق — AF_ALG غير محظور |
تشارك حاويات Kubernetes نواة المضيف، لذا يمكن الوصول إلى نفس بدائية مقبس AF_ALG
من أي حاوية على عقدة متأثرة. seccomp RuntimeDefault غير كافٍ —
أظهرت المجموعات المختبرة أن الحاويات المقبولة تحت PSS Restricted لا تزال قادرة
على فتح مقابس AF_ALG. ملف تعريف Localhost مع قاعدة حظر صريحة مطلوب.
يتطلب التخفيف أمرين: ملف تعريف JSON موجود على نظام ملفات كل عقدة، وكل مواصفات حاوية تشير إليه. تغطي الأقسام أدناه كليهما، بما في ذلك كيفية حقن ملف التعريف عالميًا دون تعديل مواصفات الحاويات الفردية.
يحل kubelet ملفات تعريف seccomp Localhost بالنسبة إلى جذر seccomp الخاص به،
والذي يكون افتراضيًا /var/lib/kubelet/seccomp. يجب أن يكون ملف التعريف موجودًا
في هذا المسار على كل عقدة قد تجدول عبء عمل.
طبق ConfigMap وDaemonSet من هذا المستودع:
kubectl apply -f templates/configmap-seccomp-profile.yaml
kubectl apply -f templates/daemonset-distribute-profile.yaml
يشغّل DaemonSet حاوية تهيئة تنسخ ملف التعريف من ConfigMap إلى جذر seccomp الخاص بـ kubelet على العقدة، ثم تركن حاوية pause بسيطة بحيث تبقى الحاوية مرئية لمراقبة الصحة. يتحمل جميع التلوثات (taints) بحيث يعمل أيضًا على عقد التحكم.
جذر seccomp غير قياسي لـ kubelet: يستخدم RKE2
/var/lib/rancher/rke2/agent/kubelet/seccomp. قم بتجاوز المسار عن طريق تعيينNODE_SECCOMP_ROOTفي بيئة حاوية التهيئة في DaemonSet قبل التطبيق.
تحقق من وجود الملف على عقدة:
kubectl -n kube-system exec -it \
$(kubectl -n kube-system get pod -l app.kubernetes.io/name=distribute-af-alg-seccomp \
-o jsonpath='{.items[0].metadata.name}') -- \
cat /var/lib/kubelet/seccomp/block-af-alg.json
بدلاً من تعديل مواصفات الحاويات الفردية أو مخططات Helm، استخدم webhook
قبول متحول (mutating admission webhook) لحقن seccompProfile تلقائيًا عند وقت القبول.
يتم توفير خيارين: Kyverno وOPA Gatekeeper.
كلا النهجين يحقنان ملف التعريف فقط عندما لا تعلن الحاوية عن واحد بالفعل، لذا تُترك الحاويات ذات الملفات التعريفية الصريحة دون تغيير.
مهم: الحاويات الموجودة قيد التشغيل لا يتم تحويرها بأثر رجعي. بعد تطبيق السياسة، أعد تشغيل عمليات النشر الخاصة بك لالتقاط ملف التعريف المحقون:
kubectl rollout restart deployment -A
يستخدم هذا القالب واجهة برمجة MutatingPolicy (policies.kyverno.io/v1)،
التي وصلت إلى مرحلة النضج العام (GA) في Kyverno 1.17. واجهة برمجة ClusterPolicy
القديمة (kyverno.io/v1) تم إهمالها في Kyverno 1.17 (يناير 2026) ومن
المخطط إزالتها في 1.20 (أكتوبر 2026)؛ لا تستخدمها للسياسات الجديدة.
يتحقق تعبير CEL matchConditions من أن seccompProfile غائب
قبل التحوير، لذا تُترك الحاويات التي تعلن عن ملف تعريف بالفعل دون تغيير.
# تثبيت Kyverno (إذا لم يكن مثبتًا بالفعل)
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update
helm upgrade --install kyverno kyverno/kyverno -n kyverno --create-namespace
# تطبيق السياسة
kubectl apply -f templates/kyverno-mutate-seccomp.yaml
تحقق من أن حاوية جديدة تتلقى ملف التعريف المحقون:
kubectl run test --image=busybox --restart=Never -- sleep 30
kubectl get pod test -o jsonpath='{.spec.securityContext.seccompProfile}'
# Expected: {"localhostProfile":"block-af-alg.json","type":"Localhost"}
kubectl delete pod test
يستخدم CRD التحوير Assign في Gatekeeper شرط pathTests لحقن ملف
التعريف فقط عندما لا يكون spec.securityContext.seccompProfile موجودًا بالفعل.
التحوير مستقر منذ Gatekeeper 3.10+؛ لا حاجة لعلامة ميزة.
# تثبيت Gatekeeper (إذا لم يكن مثبتًا بالفعل)
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update
helm install -n gatekeeper-system gatekeeper gatekeeper/gatekeeper \
--create-namespace
# تطبيق التحوير
kubectl apply -f templates/gatekeeper-assign-seccomp.yaml
تحقق:
kubectl run test --image=busybox --restart=Never -- sleep 30
kubectl get pod test -o jsonpath='{.spec.securityContext.seccompProfile}'
# Expected: {"localhostProfile":"block-af-alg.json","type":"Localhost"}
kubectl delete pod test
Gatekeeper مقابل Kyverno: يعمل نهج
Assignعلى مستوى الحقل ويتطلب تمكين webhook تحوير Gatekeeper.MutatingPolicyفي Kyverno معmatchConditionمن CEL يتعامل مع الشرط بشكل مضمّن. كلاهما يحقق نفس النتيجة — فضّل ما هو منشور بالفعل في مجموعتك.
الحاويات ذات hostPID: true أو hostNetwork: true أو
securityContext.privileged: true لديها وصول مرتفع لا يحتويه seccomp وحده
بشكل كامل. قم بمراجعة تلك الأحمال بشكل منفصل وأزل الامتيازات حيثما أمكن.
ConfigMap كمصدر للحقيقة. ملف تعريف JSON موجود في
configmap-seccomp-profile.yaml بدلاً من تضمينه في DaemonSet
أو تكراره عبر الملفات. يقوم DaemonSet بتركيبه ونسخه إلى العقدة.
تحديث ملف التعريف يعني تعديل ConfigMap واحد وإعادة تشغيل حاويات DaemonSet
— لا تتغير أي ملفات أخرى.
يستخدم DaemonSet أولوية system-node-critical. هذا يضمن أن
حاوية التوزيع لا تُطرد قبل جدولة الأحمال التي تحميها،
مما قد يترك العقد بدون ملف تعريف وحاويات عالقة في
CreateContainerError.
يستثني Gatekeeper kube-system وgatekeeper-system. حقن ملف تعريف
Localhost في حاويات النظام التي قد تسبق تثبيت DaemonSet
يخاطر بمرجع ملف تعريف مكسور إذا لم يكن الملف موجودًا بعد على
العقدة. لا تحتاج سياسة Kyverno إلى هذا الاستثناء لأن Kyverno
يتعامل مع ترتيب webhook بشكل أكثر سلاسة، ولكن يمكن إضافة قواعد exclude
هناك أيضًا إذا لزم الأمر.
حقن شرطي، وليس تجاوزًا. كل من matchCondition من CEL في MutatingPolicy
لـ Kyverno واختبار المسار MustNotExist في Gatekeeper يعني أن
سياسة القبول تعمل فقط عندما لا تحتوي الحاوية على seccompProfile موجود.
الأحمال التي تعلن بالفعل عن ملف تعريف خاص بها — بما في ذلك تلك التي
تحتاج بشكل مشروع إلى AF_ALG عبر قائمة سماح مخصصة — تُترك دون تغيير.