Libseccomp: RFE: دعم "أقصى إصدار kernel"

+1
سيساعد ذلك في جعل القوائم السوداء قابلة للاستخدام للتخفيف من مشكلات الأمان.

لكي نكون واضحين ، فإن RFE هذا مخصص لإضافة معلومات إلى جداول syscall الداخلية حول وقت تقديم syscall لأول مرة إلى Linux kernel ، وليس لإضافة منطق لتحديد ما إذا كانت النواة الحالية قيد التشغيل تدعم syscall. ومع ذلك ، إذا كنت تحاول حظر syscall ، فيمكنك القيام بذلك باستخدام libseccomp بغض النظر عما إذا كان مدعومًا على إصدار arch / ABI و kernel معين ، فإن libseccomp سيفعل الشيء الصحيح من أجلك.

يبلغ عمر هذا RFE خمس سنوات تقريبًا ، وخارج مناقشة واحدة مع cgwalters لم أر أو أسمع كثيرًا من الاهتمام بمثل هذه الميزة. مع وجود الكثير من القضايا المفتوحة الأخرى ، ومعظمها ذات أولوية أعلى ، ليس من الواضح متى سنعمل على هذا ، أو حتى إذا كان مثل هذا الشيء سيكون إضافة مفيدة.

cgwalters و drakenclimber ما رأيك في هذه القضية في 2020؟ أنا أميل إلى إغلاق هذا باسم WONTFIX ، لكني أرغب في الحصول على بعض التعليقات والتعليقات قبل أن نتخذ هذه الخطوة.

cgwalters و drakenclimber ما رأيك في هذه القضية في 2020؟ أنا أميل إلى إغلاق هذا باسم WONTFIX ، لكني أرغب في الحصول على بعض التعليقات والتعليقات قبل أن نتخذ هذه الخطوة.

بصراحة أعتقد أن هذه فكرة رائعة حقًا. يستخدم العديد من عملائي الداخليين قوائم السماح لهذا السبب بالتحديد. إذا كان عليهم استخدام denylist وأضيف syscall جديد إلى kernel ، فإن هذا النظام سيكون وسيلة أخرى للهجوم.

دعنا نتركه مفتوحا لفترة أطول قليلا. سوف أسأل من حولك داخل Oracle وأرى ما إذا كان هناك أي عملاء مهتمون بما يكفي بهذه الميزة لكي أستلمها. لكن cgwalters (أو أي شخص آخر في هذا الشأن) مرحب به تمامًا لامتلاكه إذا كان لديهم الوقت والاهتمام :).

حسنًا ، طالما أن هناك اهتمامًا ، فليس لدي مشكلة في إبقاء هذا مفتوحًا.

ما زلت أعتقد أنه سيكون مفيدًا!

يبدو أن المشكلة رقم 286 هي المشكلة الملموسة للمساعدة في دفع هذا العمل إلى الأمام ... حتى لو كان ما يقرب من خمس سنوات ؛)

أعتقد أن الخطوة الأولى نحو ذلك هي إضافة حقل جديد إلى ملف syscalls.csv يشير إلى وقت تقديم طلب syscall لأول مرة. سيكون هذا جزءًا كبيرًا من العمل نظرًا لأن لدينا حاليًا 469 syscalls محددة (!). ومع ذلك ، يمكننا استهلاك هذا العمل من أجل syscalls الحالية بقيمة "غير محددة" والتي نتعامل معها ببساطة على أنها syscall الذي يتم إنشاؤه في فجر التاريخ. بالطبع يجب إضافة جميع الإضافات الجديدة إلى جدول syscalls.csv مع إصدار kernel.

بعض الأفكار السريعة:

• تنسيق syscall.csv

#syscall (v5.8.0-rc5 2020-07-14),kver_min,x86,x86_64,...
accept,<version>,PNR,43,...

... حيث يمكن أن يكون <version> شيئًا مثل "5_8" أو "UNDEF" أو ما شابه.

• الإصدار المميز

enum kernel_version {
    KV_UNDEF = 0,
    KV_1_0,
    KV_1_1,
    KV_1_3,
    KV_2_0,
    ...
    KV_5_8,
    _KV_MAX,
};

هل إصدار النواة هو الشيء الصحيح الذي يجب تتبعه؟ هل من المضمون عدم نقل رسائل النظام الأحدث إلى backported ، على سبيل المثال ، فروع kernel المستقرة برقم إصدار أقل؟

ريد هات ستؤمن كل أنواع الأشياء إلى حباتها ، لذا لا.

إذا كان RedHat يدعم syscall إلى إصدار kernel أقدم ، فيمكنه أيضًا تصحيح نسخته من libseccomp لمطابقتها. على الرغم من أن هذا الأمر قد يكون عادلاً بالنسبة لحالات استخدام معينة ، ولكن كأسلوب لإصلاح # 286 ، أعتقد أنه قابل للتطبيق إلى حد ما. المشكلة الأخرى هي أنني لست متأكدًا من وجود أي نهج أفضل - يمكن إضافة مكالمات النظام بترتيب غير متتالي (على سبيل المثال ، تمت إضافة openat2 قبل close_range - على الرغم من أن هذا المثال لطيف من خطأي).

إذا كان RedHat يدعم syscall إلى إصدار kernel أقدم ، فيمكنه أيضًا تصحيح نسخته من libseccomp لمطابقتها.

نعم بالضبط. لا يتحكم مشروع libseccomp المنبع في توزيعات Linux المختلفة للمؤسسات وإذا قررت هذه التوزيعات الانحراف عن المشاريع الأولية (إما Linux Kernel أو libseccomp) فهي بمفردها للحصول على الدعم. بينما سنبذل قصارى جهدنا للمساعدة ، لا يمكننا التضحية بمشروع المنبع لصالح توزيعات المؤسسة هذه من خلال فريق الدعم والهندسة الخاص بهم.

كنقطة مرجعية ، تحتوي صفحة manpage syscalls(2) على بعض المعلومات التاريخية المتعلقة بوقت تقديم العديد من نداءات السحاب في kernel:

• https://www.mankier.com/2/syscalls

يمكنني القيام بعملية الكشف عن نظام syscall لمعرفة رقم إصدار لكل مكالمة نظام - والسؤال الوحيد هو ما إذا كان يجب أن يكون لدينا رقم الإصدار لكل بنية لأنني متأكد تمامًا من إضافة مكالمات syscall إلى بنى مختلفة في إصدارات مختلفة.

... السؤال الوحيد هو ما إذا كان يجب أن يكون لدينا رقم الإصدار لكل بنية لأنني متأكد تمامًا من إضافة مكالمات syscalls إلى بنى مختلفة في إصدارات مختلفة.

لقد كانوا بالتأكيد ، ولا يزالون ، بقدر ما أستطيع أن أرى. على الرغم من أنه سيكون مزعجًا بعض الشيء ، ومن المؤكد أنه سيؤدي إلى انفجار ملف CSV ، إلا أن تتبع أول ظهور لمكالمة syscall لكل قوس / ABI هو على الأرجح الشيء الصحيح الذي يجب القيام به.

أي مساعدة يمكنك تقديمها في هذا cyphar سيكون موضع تقدير كبير.