.\" -*- coding: UTF-8 -*- .\" Copyright 2008-2017 Michael Kerrisk .\" Copyright 2012, Will Drewry .\" Copyright 2017, Tyler Hicks .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH seccomp 2 "10 فبراير 2026" "صفحات دليل لينكس 6.18" .SH الاسم seccomp \- العمل على حالة الحوسبة الآمنة للعملية .SH المكتبة مكتبة سي المعيارية (\fIlibc\fP،\ \fI\-lc\fP) .SH موجز .nf .\" Kees Cook noted: Anything that uses SECCOMP_RET_TRACE returns will .\" need \fB#include \fP /* تعريف ثوابت \fBSECCOMP_*\fP */ \fB#include \fP /* تعريف \fBstruct sock_fprog\fP */ \fB#include \fP /* تعريف ثوابت \fBAUDIT_*\fP */ \fB#include \fP /* تعريف ثوابت \fBSIG*\fP */ \fB#include \fP /* تعريف ثوابت \fBPTRACE_*\fP */ \fB#include \fP /* تعريف ثوابت \fBSYS_*\fP */ \fB#include \fP .P \fBint syscall(SYS_seccomp, unsigned int \fP\fIoperation\fP\fB, unsigned int \fP\fIflags\fP\fB,\fP \fB void *\fP\fIargs\fP\fB);\fP .fi .P \fIملاحظة\fP: لا توفر glibc غلافًا للدالة \fBseccomp\fP()، مما يستلزم استخدام \fBsyscall\fP(2). .SH الوصف يعمل استدعاء النظام \fBseccomp\fP() على حالة الحوسبة الآمنة (seccomp) للعملية المستدعِيَة. .P يدعم لينكس حاليًا قيم \fIoperation\fP التالية: .TP \fBSECCOMP_SET_MODE_STRICT\fP استدعاءات النظام الوحيدة التي يُسمح للخيط المستدعِي بإجرائها هي \fBread\fP(2)، و\fBwrite\fP(2)، و\fB_exit\fP(2) (وليس \fBexit_group\fP(2))، و\fBsigreturn\fP(2). تؤدي استدعاءات النظام الأخرى إلى إنهاء الخيط المستدعِي، أو إنهاء العملية بأكملها بإشارة \fBSIGKILL\fP عندما لا يوجد سوى خيط واحد. يُعد وضع الحوسبة الآمنة الصارم مفيدًا للتطبيقات كثيفة الحسابات التي قد تحتاج إلى تنفيذ شيفرة بايت غير موثوقة، ربما استُحصل عليها بالقراءة من أنبوب أو مقبس. .IP لاحظ أنه على الرغم من أن الخيط المستدعِي لم يعد بإمكانه استدعاء \fBsigprocmask\fP(2)، إلا أنه يمكنه استخدام \fBsigreturn\fP(2) لحجب جميع الإشارات باستثناء \fBSIGKILL\fP و\fBSIGSTOP\fP. وهذا يعني أن \fBalarm\fP(2) (على سبيل المثال) ليس كافيًا لتقييد وقت تنفيذ العملية. وبدلاً من ذلك، ولإنهاء العملية بشكل موثوق، يجب استخدام \fBSIGKILL\fP. يمكن القيام بذلك باستخدام \fBtimer_create\fP(2) مع ضبط \fBSIGEV_SIGNAL\fP و\fIsigev_signo\fP على \fBSIGKILL\fP، أو باستخدام \fBsetrlimit\fP(2) لضبط الحد الصارم لـ \fBRLIMIT_CPU\fP. .IP تتوفر هذه العملية فقط إذا تم ضبط النواة مع تمكين \fBCONFIG_SECCOMP\fP. .IP يجب أن تكون قيمة \fIflags\fP تساوي 0، ويجب أن يكون \fIargs\fP هو NULL. .IP هذه العملية متطابقة وظيفيًا مع الاستدعاء: .IP .in +4n .EX prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT); .EE .in .TP \fBSECCOMP_SET_MODE_FILTER\fP تُحدد استدعاءات النظام المسموح بها بواسطة مؤشر إلى مرشح حزم بيركلي (BPF) يُمرر عبر \fIargs\fP. هذا المعامل هو مؤشر إلى \fIstruct\ sock_fprog\fP؛ يمكن تصميمه لترشيح استدعاءات نظام ومعاملات استدعاء نظام عشوائية. إذا كان المرشح غير صالح، يفشل \fBseccomp\fP()، ويعيد \fBEINVAL\fP في \fIerrno\fP. .IP إذا سمح المرشح بـ \fBfork\fP(2) أو \fBclone\fP(2)، فستُقيد أي عمليات وليدة بنفس مرشحات استدعاء النظام الخاصة بالأب. إذا سُمح بـ \fBexecve\fP(2)، فستُحفظ المرشحات الحالية عبر استدعاء \fBexecve\fP(2). .IP من أجل استخدام عملية \fBSECCOMP_SET_MODE_FILTER\fP، إما أن يمتلك الخيط المستدعِي صلاحية \fBCAP_SYS_ADMIN\fP في مساحة اسم المستخدم الخاصة به، أو يجب أن يكون بت \fIno_new_privs\fP مضبوطًا بالفعل لدى الخيط. إذا لم يكن هذا البت مضبوطًا بالفعل من قِبل سلف لهذا الخيط، فيجب على الخيط إجراء الاستدعاء التالي: .IP .in +4n .EX prctl(PR_SET_NO_NEW_PRIVS, 1); .EE .in .IP خلاف ذلك، تفشل عملية \fBSECCOMP_SET_MODE_FILTER\fP وتُعيد \fBEACCES\fP في \fIerrno\fP. يضمن هذا المتطلب عدم تمكن عملية غير مميزة من تطبيق مرشح خبيث ثم استدعاء برنامج bit\-set\-user\-ID أو أي برنامج مميز آخر باستخدام \fBexecve\fP(2)، مما قد يؤدي إلى اختراق ذلك البرنامج. (قد يتسبب مثل هذا المرشح الخبيث، على سبيل المثال، في جعل محاولة استخدام \fBsetuid\fP(2) لضبط معرفات مستخدم المستدعِي على قيم غير صفرية تُعيد القيمة 0 بدلاً من ذلك دون إجراء استدعاء النظام فعليًا. وبالتالي، قد يُخدع البرنامج للاحتفاظ بامتيازات المستخدم الخارق في ظروف يمكن فيها التأثير عليه للقيام بأشياء خطيرة لأنه لم يتخلَ فعليًا عن الامتيازات). .IP إذا سُمح بـ \fBprctl\fP(2) أو \fBseccomp\fP() بواسطة المرشح الملحق، فيمكن إضافة المزيد من المرشحات. سيؤدي هذا إلى زيادة وقت التقييم، ولكنه يسمح بمزيد من تقليل سطح الهجوم أثناء تنفيذ الخيط. .IP تتوفر عملية \fBSECCOMP_SET_MODE_FILTER\fP فقط إذا ضُبطت النواة مع تمكين \fBCONFIG_SECCOMP_FILTER\fP. .IP عندما يكون \fIflags\fP مساويًا لـ 0، تكون هذه العملية متطابقة وظيفيًا مع الاستدعاء: .IP .in +4n .EX prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, args); .EE .in .IP الرايات (\fIflags\fP) المعروفة هي: .RS .TP \fBSECCOMP_FILTER_FLAG_LOG\fP (منذ لينكس 4.14) .\" commit e66a39977985b1e69e17c4042cb290768eca9b02 ينبغي تسجيل جميع إجراءات إرجاع المرشح باستثناء \fBSECCOMP_RET_ALLOW\fP. يمكن للمسؤول تجاوز راية المرشح هذه عن طريق منع تسجيل إجراءات معينة عبر ملف \fI/proc/sys/kernel/seccomp/actions_logged\fP. .TP \fBSECCOMP_FILTER_FLAG_NEW_LISTENER\fP (منذ لينكس 5.0) .\" commit 6a21cc50f0c7f87dae5259f6cfefe024412313f6 بعد تثبيت برنامج المرشح بنجاح، يُعاد واصف ملف إشعار جديد في مساحة المستخدم. (تُضبط راية الإغلاق عند التنفيذ close\-on\-exec لواصف الملف). عندما يُعيد المرشح \fBSECCOMP_RET_USER_NOTIF\fP، سيُرسل إشعار إلى واصف الملف هذا. .IP يمكن تثبيت مرشح seccomp واحد كحد أقصى باستخدام راية \fBSECCOMP_FILTER_FLAG_NEW_LISTENER\fP لكل خيط. .IP انظر \fBseccomp_unotify\fP(2) لمزيد من التفاصيل. .TP \fBSECCOMP_FILTER_FLAG_SPEC_ALLOW\fP (منذ لينكس 4.17) .\" commit 00a02d0c502a06d15e07b857f8ff921e3e402675 عطّل تخفيف تجاوز التخزين التخميني (Speculative Store Bypass). .TP \fBSECCOMP_FILTER_FLAG_TSYNC\fP عند إضافة مرشح جديد، قم بمزامنة جميع الخيوط الأخرى للعملية المستدعِيَة مع شجرة مرشحات seccomp نفسها. "شجرة المرشحات" هي القائمة المرتبة للمرشحات الملحقة بالخيط. (إلحاق مرشحات متطابقة في استدعاءات \fBseccomp\fP() منفصلة يؤدي إلى مرشحات مختلفة من هذا المنظور). .IP إذا تعذر على أي خيط المزامنة مع نفس شجرة المرشحات، فلن يقوم الاستدعاء بإلحاق مرشح seccomp الجديد، وسيفشل، مع إرجاع أول معرف خيط عُثر عليه لا يمكنه المزامنة. ستفشل المزامنة إذا كان خيط آخر في نفس العملية في وضع \fBSECCOMP_MODE_STRICT\fP أو إذا ألحق مرشحات seccomp جديدة بنفسه، مما يؤدي إلى تباعده عن شجرة مرشحات الخيط المستدعِي. .RE .TP \fBSECCOMP_GET_ACTION_AVAIL\fP (منذ لينكس 4.14) .\" commit d612b1fd8010d0d67b5287fe146b8b55bcbb8655 اختبر لترى ما إذا كان الإجراء مدعومًا من قبل النواة. هذه العملية مفيدة للتأكد من أن النواة تعرف إجراء إرجاع مرشح أضيف حديثًا، لأن النواة تعامل جميع الإجراءات المجهولة على أنها \fBSECCOMP_RET_KILL_PROCESS\fP. .IP يجب أن تكون قيمة \fIflags\fP تساوي 0، ويجب أن يكون \fIargs\fP مؤشرًا إلى إجراء إرجاع مرشح 32\-بت غير موقع. .TP \fBSECCOMP_GET_NOTIF_SIZES\fP (منذ لينكس 5.0) .\" commit 6a21cc50f0c7f87dae5259f6cfefe024412313f6 احصل على أحجام هياكل إشعارات seccomp في مساحة المستخدم. وبما أن هذه الهياكل قد تتطور وتكبر بمرور الوقت، يمكن استخدام هذا الأمر لتحديد مقدار الذاكرة التي يجب تخصيصها لإرسال واستلام الإشعارات. .IP يجب أن تكون قيمة \fIflags\fP تساوي 0، ويجب أن يكون \fIargs\fP مؤشرًا إلى \fIstruct seccomp_notif_sizes\fP، الذي له الشكل التالي: .IP .EX struct seccomp_notif_sizes __u16 seccomp_notif; /* حجم هيكل الإشعار */ __u16 seccomp_notif_resp; /* حجم هيكل الاستجابة */ __u16 seccomp_data; /* حجم \[aq]struct seccomp_data\[aq] */ }; .EE .IP .\" انظر \fBseccomp_unotify\fP(2) لمزيد من التفاصيل. .SS المرشحات عند إضافة مرشحات عبر \fBSECCOMP_SET_MODE_FILTER\fP، يشير \fIargs\fP إلى برنامج مرشح: .P .in +4n .EX struct sock_fprog { unsigned short len; /* عدد تعليمات BPF */ struct sock_filter *filter; /* مؤشر إلى مصفوفة من تعليمات BPF */ }; .EE .in .P يجب أن يحتوي كل برنامج على تعليمة BPF واحدة أو أكثر: .P .in +4n .EX struct sock_filter { /* كتلة المرشح */ __u16 code; /* شيفرة المرشح الفعلية */ __u8 jt; /* قفز في حال الصحة */ __u8 jf; /* قفز في حال الخطأ */ __u32 k; /* حقل عام متعدد الاستخدامات */ }; .EE .in .P .\" Quoting Kees Cook: .\" If BPF even allows changing the data, it's not copied back to .\" the syscall when it runs. Anything wanting to do things like .\" that would need to use ptrace to catch the call and directly .\" modify the registers before continuing with the call. عند تنفيذ التعليمات، يعمل برنامج BPF على معلومات استدعاء النظام المتاحة (أي باستخدام وضع العنونة \fBBPF_ABS\fP) كدرء (للقراءة فقط) بالشكل التالي: .P .in +4n .EX struct seccomp_data { int nr; /* رقم استدعاء النظام */ __u32 arch; /* قيمة AUDIT_ARCH_* (انظر ) */ __u64 instruction_pointer; /* مؤشر تعليمات وحدة المعالجة المركزية */ __u64 args[6]; /* ما يصل إلى 6 معاملات لاستدعاء النظام */ }; .EE .in .P نظرًا لأن ترقيم استدعاءات النظام يختلف بين البنيات المعمارية، وتسمح بعض البنيات (مثل x86\-64) لشفرة مساحة المستخدم باستخدام اصطلاحات الاستدعاء لبنيات متعددة (وقد يختلف الاصطلاح المستخدم خلال عمر العملية التي تستخدم \fBexecve\fP(2) لتنفيذ ملفات ثنائية تستخدم اصطلاحات مختلفة)، فمن الضروري عادةً التحقق من قيمة حقل \fIarch\fP. .P يوصى بشدة باستخدام نهج "قائمة السماح" كلما أمكن ذلك لأن مثل هذا النهج أكثر قوة وبساطة. سيتعين تحديث "قائمة المنع" كلما أُضيف استدعاء نظام يحتمل أن يكون خطيرًا (أو راية أو خيار خطير إذا كانت هذه مدرجة في قائمة المنع)، وغالبًا ما يكون من الممكن تغيير تمثيل القيمة دون تغيير معناها، مما يؤدي إلى تجاوز قائمة المنع. انظر أيضًا \fICaveats\fP أدناه. .P .\" As noted by Dave Drysdale in a note at the end of .\" https://lwn.net/Articles/604515/ .\" One additional detail to point out for the x32 ABI case: .\" the syscall number gets a high bit set (__X32_SYSCALL_BIT), .\" to mark it as an x32 call. .\" .\" If x32 support is included in the kernel, then __SYSCALL_MASK .\" will have a value that is not all-ones, and this will trigger .\" an extra instruction in system_call to mask off the extra bit, .\" so that the syscall table indexing still works. حقل \fIarch\fP ليس فريدًا لجميع اصطلاحات الاستدعاء. يستخدم كل من x86\-64 ABI وx32 ABI القيمة \fBAUDIT_ARCH_X86_64\fP كـ \fIarch\fP، ويعملان على نفس المعالجات. وبدلاً من ذلك، يُستخدم القناع \fB__X32_SYSCALL_BIT\fP في رقم استدعاء النظام للتمييز بين واجهتي التطبيق الثنائية (ABIs). .P هذا يعني أن السياسة يجب أن تمنع جميع استدعاءات النظام مع \fB__X32_SYSCALL_BIT\fP أو يجب أن تتعرف على الاستدعاءات مع ضبط \fB__X32_SYSCALL_BIT\fP وبدونه. قائمة استدعاءات النظام التي سيتم منعها بناءً على \fInr\fP والتي لا تحتوي أيضًا على قيم \fInr\fP مع ضبط \fB__X32_SYSCALL_BIT\fP يمكن تجاوزها بواسطة برنامج خبيث يضبط \fB__X32_SYSCALL_BIT\fP. .P .\" commit 6365b842aae4490ebfafadfc6bb27a6d3cc54757 بالإضافة إلى ذلك، سمحت النوى السابقة للينكس 5.4 بشكل غير صحيح بـ \fInr\fP في النطاقات 512\-547 بالإضافة إلى استدعاءات النظام المقابلة لغير x32 التي أُجريت عليها عملية OR مع \fB__X32_SYSCALL_BIT\fP. على سبيل المثال، \fInr\fP == 521 و \fInr\fP == (101 | \fB__X32_SYSCALL_BIT\fP) سيؤديان إلى استدعاءات \fBptrace\fP(2) مع دلالات x32 مقابل x86_64 قد تكون مشوشة في النواة. السياسات المخصصة للعمل على نوى قبل لينكس 5.4 يجب أن تضمن منع هذه الاستدعاءات أو التعامل معها بشكل صحيح. في لينكس 5.4 والأحدث، ستفشل استدعاءات النظام هذه مع الخطأ \fBENOSYS\fP، دون القيام بأي شيء. .P يوفر حقل \fIinstruction_pointer\fP عنوان تعليمة لغة الآلة التي أجرت استدعاء النظام. قد يكون هذا مفيدًا بالاقتران مع استخدام \fI/proc/\fPpid\fI/maps\fP لإجراء فحوصات بناءً على أي منطقة (تخطيط) من البرنامج أجرت استدعاء النظام. (ربما من الحكمة قفل استدعاءات النظام \fBmmap\fP(2) و\fBmprotect\fP(2) لمنع البرنامج من تخريب مثل هذه الفحوصات). .P عند فحص القيم من \fIargs\fP، ضع في اعتبارك أن المعاملات غالبًا ما تُبتر بصمت قبل معالجتها، ولكن بعد فحص seccomp. على سبيل المثال، يحدث هذا إذا استخدم i386 ABI على نواة x86\-64: على الرغم من أن النواة لن تنظر عادةً إلى ما بعد أدنى 32 بت من المعاملات، إلا أن قيم سجلات 64 بت الكاملة ستكون موجودة في بيانات seccomp. مثال أقل إثارة للدهشة هو أنه إذا استُخدم x86\-64 ABI لإجراء استدعاء نظام يأخذ معاملًا من نوع \fIint\fP، فإن النصف الأكثر أهمية من سجل المعامل يُتجاهل بواسطة استدعاء النظام، ولكنه يكون مرئيًا في بيانات seccomp. .P يُعيد مرشح seccomp قيمة 32\-بت تتكون من جزأين: أهم 16 بتًا (المقابلة للقناع المحدد بالثابت \fBSECCOMP_RET_ACTION_FULL\fP) تحتوي على إحدى قيم "الإجراء" المدرجة أدناه؛ وأدنى 16 بتًا (المحددة بالثابت \fBSECCOMP_RET_DATA\fP) هي "بيانات" ترتبط بقيمة الإرجاع هذه. .P .\" From an Aug 2015 conversation with Kees Cook where I asked why *all* .\" filters are applied even if one of the early filters returns .\" SECCOMP_RET_KILL: .\" .\" It's just because it would be an optimization that would only speed up .\" the RET_KILL case, but it's the uncommon one and the one that doesn't .\" benefit meaningfully from such a change (you need to kill the process .\" really quickly?). We would speed up killing a program at the (albeit .\" tiny) expense to all other filtered programs. Best to keep the filter .\" execution logic clear, simple, and as fast as possible for all .\" filters. في حال وجود مرشحات متعددة، فإنه يتم تنفيذها \fIجميعها\fP، بترتيب عكسي لإضافتها إلى شجرة المرشحات؛ أي أن المرشح المثبت مؤخرًا يُنفذ أولاً. (لاحظ أنه سيتم استدعاء جميع المرشحات حتى لو أعاد أحد المرشحات السابقة \fBSECCOMP_RET_KILL\fP. يتم ذلك لتبسيط كود النواة ولتوفير تسريع بسيط في تنفيذ مجموعات المرشحات عن طريق تجنب الفحص لهذه الحالة غير الشائعة). قيمة الإرجاع لتقييم استدعاء نظام معين هي أول قيمة إجراء مرئية ذات أعلى أسبقية (إلى جانب البيانات المصاحبة لها) تُرجعها عملية تنفيذ جميع المرشحات. .P بترتيب تنازلي للأسبقية، قيم الإجراءات التي قد يُرجعها مرشح seccomp هي: .TP \fBSECCOMP_RET_KILL_PROCESS\fP (منذ لينكس 4.14) .\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945 .\" commit 0466bdb99e8744bc9befa8d62a317f0fd7fd7421 تؤدي هذه القيمة إلى إنهاء فوري للعملية، مع تفريغ الذاكرة (core dump). لا يُنفذ استدعاء النظام. وعلى النقيض من \fBSECCOMP_RET_KILL_THREAD\fP أدناه، تُنهى جميع الخيوط في مجموعة الخيوط. (لمناقشة مجموعات الخيوط، انظر وصف راية \fBCLONE_THREAD\fP في \fBclone\fP(2)). .IP تُنتهى العملية \fIكما لو\fP قُتلت بإشارة \fBSIGSYS\fP. حتى لو سُجل معالج إشارة لـ \fBSIGSYS\fP، فسيتم تجاهل المعالج في هذه الحالة وتنتهي العملية دائمًا. بالنسبة لعملية أب تنتظر هذه العملية (باستخدام \fBwaitpid\fP(2) أو ما شابه)، فإن \fIwstatus\fP المُرجع سيشير إلى أن وليدها قد أُنهي كما لو كان بإشارة \fBSIGSYS\fP. .TP \fBSECCOMP_RET_KILL_THREAD\fP (أو \fBSECCOMP_RET_KILL\fP) تؤدي هذه القيمة إلى إنهاء فوري للخيط الذي أجرى استدعاء النظام. لا يُنفذ استدعاء النظام. ستستمر الخيوط الأخرى في نفس مجموعة الخيوط في التنفيذ. .IP ينتهي الخيط \fIكما لو\fP قُتل بإشارة \fBSIGSYS\fP. انظر \fBSECCOMP_RET_KILL_PROCESS\fP أعلاه. .IP .\" See these commits: .\" seccomp: dump core when using SECCOMP_RET_KILL .\" (b25e67161c295c98acda92123b2dd1e7d8642901) .\" seccomp: Only dump core when single-threaded .\" (d7276e321ff8a53106a59c85ca46d03e34288893) قبل لينكس 4.11، لم تكن أي عملية أُنهيت بهذه الطريقة لتؤدي إلى تفريغ الذاكرة (على الرغم من أن \fBSIGSYS\fP موثق في \fBsignal\fP(7) على أنه يمتلك إجراءً مبدئيًا بالإنهاء مع تفريغ الذاكرة). منذ لينكس 4.11، ستقوم العملية أحادية الخيط بتفريغ الذاكرة إذا أُنهيت بهذه الطريقة. .IP مع إضافة \fBSECCOMP_RET_KILL_PROCESS\fP في لينكس 4.14، أُضيف \fBSECCOMP_RET_KILL_THREAD\fP كمرادف لـ \fBSECCOMP_RET_KILL\fP، من أجل التمييز بوضوح أكبر بين الإجراءين. .IP \fBملاحظة\fP: من المحتمل أن يؤدي استخدام \fBSECCOMP_RET_KILL_THREAD\fP لقتل خيط واحد في عملية متعددة الخيوط إلى ترك العملية في حالة غير متسقة بشكل دائم وربما تالفة. .TP \fBSECCOMP_RET_TRAP\fP تؤدي هذه القيمة إلى قيام النواة بإرسال إشارة \fBSIGSYS\fP موجهة للخيط إلى الخيط المسبب. (لا يُنفذ استدعاء النظام). ستُضبط حقول مختلفة في هيكل \fIsiginfo_t\fP (انظر \fBsigaction\fP(2)) المرتبط بالإشارة: .RS .IP \[bu] 3 سيحتوي \fIsi_signo\fP على \fBSIGSYS\fP. .IP \[bu] سيعرض \fIsi_call_addr\fP عنوان تعليمة استدعاء النظام. .IP \[bu] سيوضح \fIsi_syscall\fP و \fIsi_arch\fP استدعاء النظام الذي جرت محاولته. .IP \[bu] سيحتوي \fIsi_code\fP على \fBSYS_SECCOMP\fP. .IP \[bu] سيحتوي \fIsi_errno\fP على جزء \fBSECCOMP_RET_DATA\fP من قيمة إرجاع المرشح. .RE .IP سيكون عداد البرنامج كما لو أن استدعاء النظام قد حدث (أي أن عداد البرنامج لن يشير إلى تعليمة استدعاء النظام). سيحتوي سجل قيمة الإرجاع على قيمة تعتمد على البنية المعمارية؛ إذا استؤنف التنفيذ، فاصبطه على شيء مناسب لاستدعاء النظام. (الاعتماد على البنية هو لأن استبداله بـ \fBENOSYS\fP قد يكتب فوق بعض المعلومات المفيدة). .TP \fBSECCOMP_RET_ERRNO\fP تؤدي هذه القيمة إلى تمرير جزء \fBSECCOMP_RET_DATA\fP من قيمة إرجاع المرشح إلى مساحة المستخدم كقيمة \fIerrno\fP دون تنفيذ استدعاء النظام. .TP \fBSECCOMP_RET_USER_NOTIF\fP (منذ لينكس 5.0) .\" commit 6a21cc50f0c7f87dae5259f6cfefe024412313f6 حول استدعاء النظام إلى عملية مشرفة ملحقة في مساحة المستخدم للسماح لتلك العملية بتقرير ما يجب فعله باستدعاء النظام. إذا لم يكن هناك مشرف ملحق (إما لأن المرشح لم يُثبت مع راية \fBSECCOMP_FILTER_FLAG_NEW_LISTENER\fP أو لأن واصف الملف أُغلق)، يُرجع المرشح \fBENOSYS\fP (على غرار ما يحدث عندما يُرجع المرشح \fBSECCOMP_RET_TRACE\fP ولا يوجد متتبع). انظر \fBseccomp_unotify\fP(2) لمزيد من التفاصيل. .IP لاحظ أنه لن يتم إخطار عملية المشرف إذا أعاد مرشح آخر قيمة إجراء بأسبقية أعلى من \fBSECCOMP_RET_USER_NOTIF\fP. .TP \fBSECCOMP_RET_TRACE\fP عند إرجاعها، ستتسبب هذه القيمة في قيام النواة بمحاولة إخطار متتبع يعتمد على \fBptrace\fP(2) قبل تنفيذ استدعاء النظام. إذا لم يكن هناك متتبع موجود، فلن يُنفذ استدعاء النظام ويُرجع حالة فشل مع ضبط \fIerrno\fP على \fBENOSYS\fP. .IP سيُخطر المتتبع إذا طلب \fBPTRACE_O_TRACESECCOMP\fP باستخدام \fIptrace(PTRACE_SETOPTIONS)\fP. سيُخطر المتتبع بـ \fBPTRACE_EVENT_SECCOMP\fP وسيكون جزء \fBSECCOMP_RET_DATA\fP من قيمة إرجاع المرشح متاحًا للمتتبع عبر \fBPTRACE_GETEVENTMSG\fP. .IP يمكن للمتتبع تخطي استدعاء النظام عن طريق تغيير رقم استدعاء النظام إلى \-1. وبدلاً من ذلك، يمكن للمتتبع تغيير استدعاء النظام المطلوب عن طريق تغيير استدعاء النظام إلى رقم استدعاء نظام صالح. إذا طلب المتتبع تخطي استدعاء النظام، فسيظهر استدعاء النظام وكأنه يُرجع القيمة التي يضعها المتتبع في سجل قيمة الإرجاع. .IP .\" This was changed in ce6526e8afa4. .\" A related hole, using PTRACE_SYSCALL instead of SECCOMP_RET_TRACE, was .\" changed in arch-specific commits, e.g., 93e35efb8de4 for X86 and .\" 0f3912fd934c for ARM. قبل لينكس 4.8، لن يُشغل فحص seccomp مرة أخرى بعد إخطار المتتبع. (وهذا يعني أنه في النوى القديمة، \fBيجب ألا\fP تسمح البيئات المعزولة القائمة على seccomp باستخدام \fBptrace\fP(2) \- حتى للعمليات المعزولة الأخرى \- بدون عناية فائقة؛ إذ يمكن للمتتبعين استخدام هذه الآلية للهروب من بيئة seccomp المعزولة). .IP لاحظ أنه لن يتم إخطار عملية المتتبع إذا أعاد مرشح آخر قيمة إجراء بأسبقية أعلى من \fBSECCOMP_RET_TRACE\fP. .TP \fBSECCOMP_RET_LOG\fP (منذ لينكس 4.14) .\" commit 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4 تؤدي هذه القيمة إلى تنفيذ استدعاء النظام بعد تسجيل إجراء إرجاع المرشح. يمكن للمسؤول تجاوز تسجيل هذا الإجراء عبر ملف \fI/proc/sys/kernel/seccomp/actions_logged\fP. .TP \fBSECCOMP_RET_ALLOW\fP تؤدي هذه القيمة إلى تنفيذ نداء النظام. .P .\" commit 4d3b0b05aae9ee9ce0970dc4cc0fb3fad5e85945 .\" إذا حُددت قيمة إجراء بخلاف القيم المذكورة أعلاه، فسيُعامل إجراء المرشح إما كـ \fBSECCOMP_RET_KILL_PROCESS\fP (منذ لينكس 4.14) أو \fBSECCOMP_RET_KILL_THREAD\fP (في لينكس 4.13 وما قبله). .SS "واجهات /proc" توفر الملفات الموجودة في الدليل \fI/proc/sys/kernel/seccomp\fP معلومات وضبط seccomp إضافي: .TP \fIactions_avail\fP (منذ لينكس 4.14) .\" commit 8e5f1ad116df6b0de65eac458d5e7c318d1c05af قائمة مرتبة للقراءة فقط لإجراءات إرجاع مرشح seccomp في شكل سلسلة نصية. الترتيب، من اليسار إلى اليمين، هو بترتيب تنازلي للأسبقية. تمثل القائمة مجموعة إجراءات إرجاع مرشح seccomp التي تدعمها النواة. .TP \fIactions_logged\fP (منذ لينكس 4.14) .\" commit 0ddec0fc8900201c0897b87b762b7c420436662f قائمة مرتبة للقراءة والكتابة لإجراءات إرجاع مرشح seccomp المسموح بتسجيلها. لا يلزم أن تكون عمليات الكتابة في الملف مرتبة، ولكن عمليات القراءة من الملف ستكون مرتبة بنفس طريقة ملف \fIactions_avail\fP. .IP من المهم ملاحظة أن قيمة \fIactions_logged\fP لا تمنع تسجيل إجراءات إرجاع مرشح معينة عندما يُضبط النظام الفرعي للتدقيق لتدقيق مهمة ما. إذا لم يُعثر على الإجراء في ملف \fIactions_logged\fP، فإن القرار النهائي بشأن تدقيق الإجراء لتلك المهمة يُترك في النهاية للنظام الفرعي للتدقيق ليقرر لجميع إجراءات إرجاع المرشح بخلاف \fBSECCOMP_RET_ALLOW\fP. .IP .\" لا تُقبل السلسلة "allow" في ملف \fIactions_logged\fP لأنه لا يمكن تسجيل إجراءات \fBSECCOMP_RET_ALLOW\fP. ستفشل محاولة كتابة "allow" في الملف مع الخطأ \fBEINVAL\fP. .SS "تسجيل التدقيق لإجراءات seccomp" .\" commit 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4 .\" or auditing could be enabled via the netlink API (AUDIT_SET) منذ لينكس 4.14، توفر النواة وسيلة لتسجيل الإجراءات التي تعيدها مرشحات seccomp في سجل التدقيق. تتخذ النواة قرار تسجيل إجراء بناءً على نوع الإجراء، وما إذا كان الإجراء موجودًا في ملف \fIactions_logged\fP، وما إذا كان تدقيق النواة مفعلًا (على سبيل المثال، عبر خيار إقلاع النواة \fIaudit=1\fP). القواعد هي كما يلي: .IP \[bu] 3 إذا كان الإجراء \fBSECCOMP_RET_ALLOW\fP، فلا يُسجل الإجراء. .IP \[bu] وإلا، إذا كان الإجراء إما \fBSECCOMP_RET_KILL_PROCESS\fP أو \fBSECCOMP_RET_KILL_THREAD\fP، وظهر هذا الإجراء في ملف \fIactions_logged\fP، فيُسجل الإجراء. .IP \[bu] وإلا، إذا طلب المرشح التسجيل (راية \fBSECCOMP_FILTER_FLAG_LOG\fP) وظهر الإجراء في ملف \fIactions_logged\fP، فيُسجل الإجراء. .IP \[bu] وإلا، إذا كان تدقيق النواة مفعلًا وكانت العملية تخضع للتدقيق (\fBautrace\fP(8))، فيُسجل الإجراء. .IP \[bu] خلاف ذلك، لا يُسجل الإجراء. .SH "قيمة الإرجاع" عند النجاح، يعيد \fBseccomp\fP() القيمة 0. عند الخطأ، إذا استُخدمت \fBSECCOMP_FILTER_FLAG_TSYNC\fP، فإن القيمة المعادة هي معرف الخيط (thread) الذي تسبب في فشل المزامنة. (هذا المعرف هو معرف خيط نواة من النوع الذي يعيده \fBclone\fP(2) و \fBgettid\fP(2)). في الأخطاء الأخرى، تُعاد \-1، ويُضبط \fIerrno\fP للإشارة إلى الخطأ. .SH الأخطاء يمكن أن يفشل \fBseccomp\fP() للأسباب التالية: .TP \fBEACCES\fP لم يمتلك المستدعِي قدرة \fBCAP_SYS_ADMIN\fP في مساحة أسماء المستخدم الخاصة به، أو لم يضبط \fIno_new_privs\fP قبل استخدام \fBSECCOMP_SET_MODE_FILTER\fP. .TP \fBEBUSY\fP أثناء تثبيت مرشح جديد، حُددت الراية \fBSECCOMP_FILTER_FLAG_NEW_LISTENER\fP، ولكن ثُبِّت مرشح سابق بالفعل مع هذه الراية. .TP \fBEFAULT\fP ‏\fIargs\fP لم يكن عنوانًا صالحًا. .TP \fBEINVAL\fP العملية \fIoperation\fP غير معروفة أو غير مدعومة من قِبل إصدار النواة هذا أو الضبط. .TP \fBEINVAL\fP الرايات \fIflags\fP المحددة غير صالحة للعملية \fIoperation\fP المعطاة. .TP \fBEINVAL\fP تضمنت العملية \fIoperation\fP القيمة \fBBPF_ABS\fP، ولكن الإزاحة المحددة لم تكن محاذية لحد 32 بت أو تجاوزت \fIsizeof(struct\ seccomp_data)\fP. .TP \fBEINVAL\fP .\" See kernel/seccomp.c::seccomp_may_assign_mode() in Linux 3.18 sources وُضع وضع حوسبة آمن بالفعل، وتختلف العملية \fIoperation\fP عن الإعداد الحالي. .TP \fBEINVAL\fP حددت العملية \fIoperation\fP القيمة \fBSECCOMP_SET_MODE_FILTER\fP، ولكن برنامج المرشح الذي تشير إليه \fIargs\fP لم يكن صالحًا أو كان طول برنامج المرشح صفرًا أو تجاوز \fBBPF_MAXINSNS\fP (4096) تعليمة. .TP \fBENOMEM\fP نفدت الذاكرة. .TP \fBENOMEM\fP .\" ENOMEM in kernel/seccomp.c::seccomp_attach_filter() in Linux 3.18 sources تجاوز الطول الإجمالي لجميع برامج المرشحات الملحقة بخيط الاستدعاء الحد \fBMAX_INSNS_PER_PATH\fP (32768) تعليمة. لاحظ أنه لأغراض حساب هذا الحد، يتحمل كل برنامج مرشح موجود مسبقًا عقوبة إضافية قدرها 4 تعليمات. .TP \fBEOPNOTSUPP\fP حددت العملية \fIoperation\fP القيمة \fBSECCOMP_GET_ACTION_AVAIL\fP، ولكن النواة لا تدعم إجراء إرجاع المرشح المحدد بواسطة \fIargs\fP. .TP \fBESRCH\fP تسبب خيط آخر في حدوث فشل أثناء مزامنة الخيوط، ولكن لم يمكن تحديد معرفه. .SH المعايير لينكس. .SH التاريخ .\" FIXME . Add glibc version لينكس 3.17. .SH ملاحظات بدلاً من ترميز مرشحات seccomp يدويًا كما هو موضح في المثال أدناه، قد تفضل استخدام مكتبة \fIlibseccomp\fP، التي توفر واجهة برمجية لتوليد مرشحات seccomp. .P يوفر الحقل \fISeccomp\fP في ملف \fI/proc/\fPpid\fI/status\fP طريقة لعرض وضع seccomp لعملية ما؛ انظر \fBproc\fP(5). .P يوفر \fBseccomp\fP() مجموعة موسعة من الوظائف التي توفرها عملية \fBprctl\fP(2) \fBPR_SET_SECCOMP\fP (التي لا تدعم الرايات \fIflags\fP). .P .\" منذ لينكس 4.4، يمكن استخدام عملية \fBptrace\fP(2) \fBPTRACE_SECCOMP_GET_FILTER\fP لتفريغ مرشحات seccomp الخاصة بالعملية. .SS "دعم المعماريات لمرشح seccomp BPF" .\" Check by grepping for HAVE_ARCH_SECCOMP_FILTER in Kconfig files in .\" kernel source. Last checked in Linux 4.16-rc source. يتوفر دعم المعمارية لترشيح seccomp BPF على المعماريات التالية: .IP \[bu] 3 x86\-64, i386, x32 (منذ لينكس 3.5) .PD 0 .IP \[bu] ARM (منذ لينكس 3.8) .IP \[bu] s390 (منذ لينكس 3.8) .IP \[bu] MIPS (منذ لينكس 3.16) .IP \[bu] ARM\-64 (منذ لينكس 3.19) .IP \[bu] PowerPC (منذ لينكس 4.3) .IP \[bu] Tile (منذ لينكس 4.3) .IP \[bu] .\" User mode Linux since Linux 4.6 PA\-RISC (منذ لينكس 4.6) .PD .\" .SS تحذيرات هناك تفاصيل دقيقة متنوعة يجب مراعاتها عند تطبيق مرشحات seccomp على برنامج، بما في ذلك ما يلي: .IP \[bu] 3 بعض نداءات النظام التقليدية لها تطبيقات في مساحة المستخدم في \fBvdso\fP(7) على العديد من المعماريات. تشمل الأمثلة البارزة \fBclock_gettime\fP(2) و \fBgettimeofday\fP(2) و \fBtime\fP(2). في مثل هذه المعماريات، لن يكون لترشيح seccomp لهذه النداءات أي تأثير. (ومع ذلك، هناك حالات قد تتراجع فيها تطبيقات \fBvdso\fP(7) وتستدعي نداء النظام الحقيقي، وفي هذه الحالة سترى مرشحات seccomp نداء النظام). .IP \[bu] يعتمد ترشيح Seccomp على أرقام نداءات النظام. ومع ذلك، لا تستدعي التطبيقات عادةً نداءات النظام مباشرة، بل تستدعي دوال غلاف في مكتبة C والتي بدورها تستدعي نداءات النظام. وبناءً على ذلك، يجب الانتباه لما يلي: .RS .IP \[bu] 3 قد تستخدم أغلفة glibc لبعض نداءات النظام التقليدية في الواقع نداءات نظام بأسماء مختلفة في النواة. على سبيل المثال، تستخدم دالة الغلاف \fBexit\fP(2) في الواقع نداء النظام \fBexit_group\fP(2)، وتستدعي دالة الغلاف \fBfork\fP(2) في الواقع \fBclone\fP(2). .IP \[bu] قد يختلف سلوك دوال الغلاف عبر المعماريات، وفقًا لمجموعة نداءات النظام الموفرة على تلك المعماريات. بمعنى آخر، قد تستدعي نفس دالة الغلاف نداءات نظام مختلفة على معماريات مختلفة. .IP \[bu] أخيرًا، يمكن أن يتغير سلوك دوال الغلاف عبر إصدارات glibc. على سبيل المثال، في الإصدارات القديمة، كانت دالة غلاف glibc لـ \fBopen\fP(2) تستدعي نداء النظام الذي يحمل نفس الاسم، ولكن بدءًا من glibc 2.26، انتقل التطبيق إلى استدعاء \fBopenat\fP(2) على جميع المعماريات. .RE .P والنتيجة المترتبة على النقاط المذكورة أعلاه هي أنه قد يكون من الضروري الترشيح لنداء نظام آخر غير المتوقع. توفر صفحات الدليل المتنوعة في القسم 2 تفاصيل مفيدة حول الفروق بين دوال الغلاف ونداءات النظام الأساسية في الأقسام الفرعية المعنونة \fIC library/kernel differences\fP. .P .\" علاوة على ذلك، لاحظ أن تطبيق مرشحات seccomp قد يتسبب في حدوث علل (bugs) في التطبيق، عندما تتسبب المرشحات في إخفاقات غير متوقعة للعمليات المشروعة التي قد يحتاج التطبيق إلى تنفيذها. قد لا تُكتشف هذه العلل بسهولة عند اختبار مرشحات seccomp إذا حدثت في مسارات برمجية نادرة الاستخدام في التطبيق. .SS "تفاصيل BPF الخاصة بـ Seccomp" لاحظ تفاصيل BPF التالية الخاصة بمرشحات seccomp: .IP \[bu] 3 معدلات الحجم \fBBPF_H\fP و \fBBPF_B\fP غير مدعومة: يجب أن تقوم جميع العمليات بتحميل وتخزين كلمات (4 بايت) (\fBBPF_W\fP). .IP \[bu] للوصول إلى محتويات مخزن \fIseccomp_data\fP المؤقت، استخدم معدل وضع العنونة \fBBPF_ABS\fP. .IP \[bu] ينتج عن معدل وضع العنونة \fBBPF_LEN\fP معامل وضع فوري قيمته هي حجم مخزن \fIseccomp_data\fP المؤقت. .SH أمثلة يقبل البرنامج أدناه أربعة وسائط أو أكثر. الوسائط الثلاثة الأولى هي رقم نداء نظام، ومعرف معمارية رقمي، ورقم خطأ. يستخدم البرنامج هذه القيم لإنشاء مرشح BPF يُستخدم في وقت التشغيل لإجراء الفحوصات التالية: .IP \[bu] 3 إذا لم يكن البرنامج يعمل على المعمارية المحددة، فإن مرشح BPF يتسبب في فشل نداءات النظام مع الخطأ \fBENOSYS\fP. .IP \[bu] إذا حاول البرنامج تنفيذ نداء النظام بالرقم المحدد، فإن مرشح BPF يتسبب في فشل نداء النظام، مع ضبط \fIerrno\fP على رقم الخطأ المحدد. .P تحدد وسائط سطر الأوامر المتبقية مسار ووسائط إضافية لبرنامج يجب على البرنامج المثال محاولة تنفيذه باستخدام \fBexecv\fP(3) (دالة مكتبية تستخدم نداء النظام \fBexecve\fP(2)). تظهر أدناه بعض عمليات تشغيل البرنامج كمثال. .P أولاً، نعرض المعمارية التي نعمل عليها (x86\-64) ثم ننشئ دالة صدفة تبحث عن أرقام نداءات النظام في هذه المعمارية: .P .in +4n .EX $\fB uname \-m\fP; x86_64 $ \f[B]syscall_nr() { cat /usr/src/linux/arch/x86/syscalls/syscall_64.tbl | \[rs] awk \[aq]$2 != \[dq]x32\[dq] && $3 == \[dq]\[aq]$1\[aq]\[dq] { print $1 }\[aq] }\fR; .EE .in .P عندما يرفض مرشح BPF نداء نظام (الحالة [2] أعلاه)، فإنه يتسبب في فشل نداء النظام برقم الخطأ المحدد في سطر الأوامر. في التجارب الموضحة هنا، سنستخدم رقم الخطأ 99: .P .in +4n .EX $\fB errno 99\fP; EADDRNOTAVAIL 99 Cannot assign requested address .EE .in .P في المثال التالي، نحاول تشغيل الأمر \fBwhoami\fP(1)، لكن مرشح BPF يرفض نداء النظام \fBexecve\fP(2)، بحيث لا يُنفذ الأمر أبدًا: .P .in +4n .EX $\fB syscall_nr execve\fP; 59 $\fB ./a.out\fP; Usage: ./a.out [] Hint for : AUDIT_ARCH_I386: 0x40000003 AUDIT_ARCH_X86_64: 0xC000003E $\fB ./a.out 59 0xC000003E 99 /bin/whoami\fP; execv: Cannot assign requested address .EE .in .P في المثال التالي، يرفض مرشح BPF نداء النظام \fBwrite\fP(2)، بحيث أنه على الرغم من تشغيل الأمر \fBwhoami\fP(1) بنجاح، إلا أنه لا يتمكن من كتابة أي مخرجات: .P .in +4n .EX $\fB syscall_nr write\fP; 1 $\fB ./a.out 1 0xC000003E 99 /bin/whoami\fP; .EE .in .P في المثال الأخير، يرفض مرشح BPF نداء نظام لا يستخدمه الأمر \fBwhoami\fP(1)، لذا يتمكن من التنفيذ بنجاح وإخراج المخرجات: .P .in +4n .EX $\fB syscall_nr preadv\fP; 295 $\fB ./a.out 295 0xC000003E 99 /bin/whoami\fP; cecilia .EE .in .SS "مصدر البرنامج" .\" SRC BEGIN (seccomp.c) .EX #include #include #include #include #include #include #include #include #include #include \& #define X32_SYSCALL_BIT 0x40000000 \& static int install_filter(int syscall_nr, unsigned int t_arch, int f_errno) { unsigned int upper_nr_limit = 0xffffffff; \& /* نفترض أن AUDIT_ARCH_X86_64 تعني ABI x86\-64 العادي (في ABI x32، تحتوي جميع نداءات النظام على بت 30 مضبوطًا في حقل \[aq]nr\[aq]، مما يعني أن الأرقام هي >= X32_SYSCALL_BIT). */ if (t_arch == AUDIT_ARCH_X86_64) upper_nr_limit = X32_SYSCALL_BIT \- 1; \& struct sock_filter filter[] = { /* [0] تحميل المعمارية من مخزن \[aq]seccomp_data\[aq] المؤقت إلى المركم. */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, arch))), \& /* [1] القفز للأمام 5 تعليمات إذا كانت المعمارية لا تطابق \[aq]t_arch\[aq]. */ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, t_arch, 0, 5), \& /* [2] تحميل رقم نداء النظام من مخزن \[aq]seccomp_data\[aq] المؤقت إلى المركم. */ BPF_STMT(BPF_LD | BPF_W | BPF_ABS, (offsetof(struct seccomp_data, nr))), \& /* [3] فحص ABI \- مطلوب فقط لـ x86\-64 في حالات استخدام قائمة الحظر. استخدم BPF_JGT بدلاً من الفحص ضد قناع البتات لتجنب الاضطرار لإعادة تحميل رقم نداء النظام. */ BPF_JUMP(BPF_JMP | BPF_JGT | BPF_K, upper_nr_limit, 3, 0), \& /* [4] القفز للأمام تعليمية واحدة إذا كان رقم نداء النظام لا يطابق \[aq]syscall_nr\[aq]. */ BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, syscall_nr, 0, 1), \& /* [5] تطابق المعمارية ونداء النظام: لا تنفذ نداء النظام، وأعد \[aq]f_errno\[aq] في \[aq]errno\[aq]. */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (f_errno & SECCOMP_RET_DATA)), \& /* [6] وجهة عدم تطابق رقم نداء النظام: السماح بنداءات النظام الأخرى. */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW), \& /* [7] وجهة عدم تطابق المعمارية: قتل العملية. */ BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS), }; \& struct sock_fprog prog = { .len = countof(filter), .filter = filter, }; \& if (syscall(SYS_seccomp, SECCOMP_SET_MODE_FILTER, 0, &prog)) { perror("seccomp"); return 1; } \& return 0; } \& int main(int argc, char *argv[]) { if (argc < 5) { fprintf(stderr, "Usage: " "%s []\[rs]n" "Hint for : AUDIT_ARCH_I386: 0x%X\[rs]n" " AUDIT_ARCH_X86_64: 0x%X\[rs]n" "\[rs]n", argv[0], AUDIT_ARCH_I386, AUDIT_ARCH_X86_64); exit(EXIT_FAILURE); } \& if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("prctl"); exit(EXIT_FAILURE); } \& if (install_filter(strtol(argv[1], NULL, 0), strtoul(argv[2], NULL, 0), strtol(argv[3], NULL, 0))) exit(EXIT_FAILURE); \& execv(argv[4], &argv[4]); perror("execv"); exit(EXIT_FAILURE); } .EE .\" SRC END .SH "انظر أيضًا" \fBbpfc\fP(1), \fBstrace\fP(1), \fBbpf\fP(2), \fBprctl\fP(2), \fBptrace\fP(2), \fBseccomp_unotify\fP(2), \fBsigaction\fP(2), \fBproc\fP(5), \fBsignal\fP(7), \fBsocket\fP(7) .P صفحات متنوعة من مكتبة \fIlibseccomp\fP، تشمل: \fBscmp_sys_resolver\fP(1) و \fBseccomp_export_bpf\fP(3) و \fBseccomp_init\fP(3) و \fBseccomp_load\fP(3) و \fBseccomp_rule_add\fP(3). .P ملفات مصدر النواة \fIDocumentation/networking/filter.rst\fP و \fIDocumentation/userspace\-api/seccomp_filter.rst\fP. .P McCanne, S.\& and Jacobson, V.\& (1992) \fIThe BSD Packet Filter: A New Architecture for User\-level Packet Capture\fP, Proceedings of the USENIX Winter 1993 Conference .UR http:\://www.tcpdump.org/papers/bpf\-usenix93.pdf .UE .P Terence Kelly and Edison Fuh (2025) Sandboxing: Foolproof Boundaries vs.\& Unbounded Foolishness .UR https:\://dl.acm.org/doi/pdf/10.1145/3733699 .UE .PP .SH ترجمة تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي . .PP هذه الترجمة هي وثيقة مجانية؛ راجع .UR https://www.gnu.org/licenses/gpl-3.0.html رخصة جنو العامة الإصدار 3 .UE أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات. .PP إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: .MT kde-l10n-ar@kde.org .ME .