توقيع الملفات التنفيذية تحت لينكس

Question

لأسباب أمنية، من المرغوب فيه التحقق من سلامة التعليمات البرمجية قبل التنفيذ، تجنب البرمجيات العبث من قبل المهاجم. لذلك، سؤالي هو

كيفية تسجيل التعليمات البرمجية القابلة للتنفيذ وتشغيل البرنامج الموثوق فقط بموجب Linux؟

لقد قرأت عمل Van Doom وآخرون., تصميم وتنفيذ الملفات التنفيذية الموقعة لينكس, ، و IBM TLC. (عميل Linux الموثوق به) بواسطة Safford & Zohar. يستخدم TLC وحدة تحكم TPM، ما هو لطيف، ولكن الورقة من عام 2005 ولم أتمكن من العثور على البدائل الحالية.

هل تعرف خيارات أخرى؟

تحديث: وحول نظام التشغيل الآخرين؟ opensolaris؟ عائلة BSD؟

Answer 1

ال digsig. وحدة النواة تنفذ التحقق من الثنائيات الموقعة بواسطة أداة تسمى bsign. وبعد ومع ذلك، لم يكن هناك أي عمل على الإصدار 2.6.21 من نواة Linux.

Answer 2

أدرك أن هذا سؤال قديم لكنني وجدت الآن.

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

لكننا قررنا التوقف عن متابعة ذلك لأنها تواجه العديد من المشاكل التي كانت كبيرة جدا لتبرير التعقيد:

• لم نبني بعد دعم المكتبات الموقعة. وبعد تتطلب المكتبات الموقعة أيضا تعديل ld.so لودر و dlopen(3) آلية. لم يكن هذا أمرا مستحيلا ولكنه فعلت تعقيد الواجهة: هل يجب أن يكون لدينا محمل يطلب من النواة التحقق من صحة توقيع أو يجب أن يتم حساب الحساب بالكامل في مساحة المستخدمين؟ كيف يحمي المرء ضد strace(2)عملية D إذا تم هذا الجزء من التحقق من الصحة في مساحة المستخدمين؟ هل سيضطرنا في منع strace(2) تماما على هذا النظام؟

  ماذا نفعل البرامج التي توفر لودر الخاصة بهم?

• تتم كتابة العديد من البرامج العديدة باللغات التي لا تترجم إلى كائنات ELF. سنحتاج إلى توفير اللغة الخاصة باللغة تعديلات على bash, perl, python, java, awk, sed, وهلم جرا، لكل من المترجمين الفوريين قادرين على ايضا التحقق من صحة التواقيع. نظرا لأن معظم هذه البرامج هي نص عادي بتنسيق مجاني يفتقرون إلى الهيكل الذي جعل تضمين التواقيع الرقمية في ملفات كائن ELF سهلا للغاية. أين سيتم تخزين التوقيعات؟ في البرامج النصية؟ في السمات الموسعة؟ في قاعدة بيانات خارجية للتوقيعات؟

• العديد من المترجمين الفوريين مفتوح على مصراعيه حول ما يسمحون به؛ bash(1) يمكن التواصل مع الأنظمة البعيدة تماما من تلقاء نفسها استخدام echo و /dev/tcp, ، ويمكن بسهولة خداعها في تنفيذ أي شيء يحتاج المهاجم إلى القيام به. وقعت أم لا، لا يمكنك الوثوق بها بمجرد التحكم في القراصنة.

• يأتي الدافع الرئيسي لدعم الملفات التنفيذية الموقعة من Rootkits لاستبدال النظام المقدم من النظام /bin/ps, /bin/ps, /bin/kill, ، وهلم جرا. نعم، هناك أسباب مفيدة أخرى قد وقعت تنفيذية. ومع ذلك، حصلت Rootkits أكثر إثارة للإعجاب بشكل كبير مع مرور الوقت، مع العديد من الاعتماد على نواة الخارقة لإخفاء أنشطتهم من المسؤولين. بمجرد اختراق النواة، انتهت اللعبة بأكملها. نتيجة لتطور Rootkits، فإن الأدوات التي نأمل أن نمنعها من استخدامها كانت تنخفض عن صالح في مجتمع القرصنة.

• كانت واجهة تحميل وحدة Kernel مفتوحة على مصراعيها. مرة واحدة في العملية root امتياز، كان من السهل ضخ وحدة النواة دون أي فحص. كان بإمكاننا أيضا كتابة مدقق آخر لنقاض النواة ولكن البنية التحتية في النواة حول الوحدات كانت بدائية للغاية.

Answer 3

نموذج جنو / لينكس / فوس يشجع فعلا العبث - من نوع. يجب أن يكون المستخدمون وماكينات التوزيع حرة في تعديل البرنامج (العبث به) البرنامج ليناسب احتياجاتهم. حتى مجرد إعادة ترجمة البرنامج (دون تغيير أي رمز مصدر) للتخصيص هو شيء يتم فيه في كثير من الأحيان، ولكن من شأنه أن يكسر توقيع التعليمات البرمجية الثنائية. نتيجة لذلك، لا يناسب نموذج توقيع التعليمات البرمجية الثنائية بشكل جيد إلى جنو / لينكس / فوس.

بدلا من ذلك، يعتمد هذا النوع من البرامج بشكل أكبر على توليد التواقيع و / أو اجراض آمنة لحزم المصدر. بالاشتراك مع نموذج توزيع حزمة موثوق به موثوق به، يمكن أن يتم ذلك بشكل آمن (إن لم يكن أكثر من ذلك، تجاه الشفافية في التعليمات البرمجية المصدر) كوقعات ثنائية.

Answer 4

الق نظرة على هذا: http://linux-ima.sourceforge.net/

إنه لا يوقع بعد، لكنه لا يزال يتيح التحقق.

Answer 5

يمكنني الإجابة على السؤال من منظور Solaris 10 & 11 OS، يتم توقيع جميع الثنائيات. للتحقق من استخدام التوقيع "Elfsign" ...

$ elfsign verify -v /usr/bin/bash
elfsign: verification of /usr/bin/bash passed.
format: rsa_sha1.
signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11.
signed on: Fri Oct 04 17:06:13 2013.

تمت إضافة Oracle مؤخرا عملية تمهيدية تم التحقق منها ل Solaris 11 أيضا، لمزيد من التفاصيل Solaris التحقق من التمهيد مقدمة

هناك بعض الشوكات الصف الإنتاجية لرمز OpenSolaris، وهي ثلاث تستحق التحقيق هي Illumos و Smartos and Omnios.

Answer 6

إلقاء نظرة على ميدوسا DS9.. وبعد لعبت معها لفترة طويلة (طويلوقبل الوقت، ولكن إذا كنت أتذكر بشكل صحيح، يمكنك تسجيل ثنائيات محددة وأي تعديل غير مسموح به على مستوى النواة. بالطبع، يمكن تجاوزه مع الوصول المحلي إلى الجهاز، لكنه لم يكن الأمر سهلا حقا. هناك برنامج مخفي ذكي، يسمى Constable، والتحقق من كل ما يحدث على الجهاز وإذا حدث شيء خارج عن العادي، فإنه يبدأ الصراخ.

Answer 7

لم أحاول ذلك أبدا، لكن إلقاء نظرة على: http://blog.codenoise.com/signelf-digitally-signing-elf-vinearies.. وبعد يعمل الحل دون الحاجة إلى دعم kernel، ويبدو أن تكون جاهزا للذهاب.

يمكن العثور على رمز الموقع في http://sourceforge.net/projects/signelf/

لا يحل سؤال "تشغيل التعليمات البرمجية الموثوق فقط في نظام Linux، ولكنه يحل المشكلة جزئيا من خلال اتخاذ طريقة للبرنامج للكشف عن نفسه من العبث / الفساد المحتمل

Answer 8

http://en.wikipedia.org/wiki/pkcs.

استخدم علامة PKCS7 (S / MIME). توليد زوجك الخاص / زوج المفتاح الخاص الخاص بك، قم بتسجيل الدخول الذاتي، ثم قم بتوقيع ملفك باستخدام المفتاح الخاص و Cert باستخدام PKCS7. سيتم إرفاق المركز عليه، ثم يمكنه التحقق من نفسها عند وقت التشغيل باستخدام أمر Openssl (رجل Smime أو مجرد مساعدة Openssl). هذا مقاوم للعبث لأنه على الرغم من أن المفتاح العمومي في الملفات التي تعطيه، لا يمكن إنشاء توقيع S / MIME الخاص بهذا المفتاح العام إلا مع المفتاح الخاص الذي لن توزع فيه. لذلك إذا تم توقيع الملف بواسطة سيرتك الشخصية، فيجب أن يكون قد تم توقيعه من قبل شخص لديه المفتاح الخاص وبالتالي لم تعطي المفتاح الخاص لأي شخص، يجب أن يأتي منك.

إليك كيفية جعل الشهادة الموقعة ذاتيا.

http://www.akadia.com/services/ssh_test_certificate.html.

سيتعين عليك إقناع Openssl بالثقة بالثقة بك كجذر للسلطة (-Cafile)، ثم التحقق من ذلك مع الجذر، وأيضا التحقق من المرض في الملف هو لك (Hash The Cert) والتحقق من التجزئة. لاحظ أنه على الرغم من أنه لا يتم توثيقه، فإن حالة الخروج من Openssl يعكس صلاحية تسجيل الدخول الذي تقوم بالتحقق عند التحقق من التمييز. إنه 0 إذا كان يطابق، غير صفر إذا لم يحدث ذلك.

لاحظ أن كل هذا غير آمن لأنه إذا كان الشيك في التعليمات البرمجية الخاصة بك، فيمكنه ببساطة إزالة الشيك إذا أرادوا التغلب عليك. إن الطريقة الآمنة الوحيدة للقيام بذلك ستكون لديها مدقق في نظام التشغيل ولديها تحقق من الثنائي ورفض تشغيله إذا لم يتم توقيعه. ولكن نظرا لأنه لا يوجد أي مدقق في نظام التشغيل ويمكن تعديل Linux لإزالة / تجاوزه على أي حال ... ما هذا جيد حقا بالنسبة للكشف عن الملفات الفاسدة أكثر من محاولة الحفاظ على الناس من تجاوزك.

Answer 9

أوافق على أن الفلسفة المحيطة لينكس، جنو وآخرون. يدور حول العبث. من ناحية أخرى، أعتقد أيضا أن بعض النظم تستحق الحماية من نقاط الضعف مثل العبث البرمجيات، والتي يمكن أن تقوض خصوصية وسلامة مستخدمي النظام.

لا تستطيع تطبيقات النواة مواكبة دورة التطور السريع للنواة نفسها. أوصي بدلا من ذلك لتنفيذ شكل من أشكال التحقق من توقيع الملف القابل للتنفيذ باستخدام أدوات المستخدمين. ضع ملفات تنفيذية في أرشيف أو صورة نظام الملفات وتوقيع الصورة باستخدام مفتاح خاص؛ إذا كان هذا المفتاح الخاص في آلات التطوير الخاصة بك (خاص)، عندما يتم اختراق الخادم الخاص بك، لا يزال المهاجمون ليس لديهم طريقة لتوقيع صورهم الخاصة وحقن رمزهم دون خداع النظام لتركيب الصور غير الموقعة. يمتد أبعد من السلسلة:

• اجعل خدماتك الواردة في صور للقراءة فقط للقراءة فقط؛
• اطلب تشغيل الجهاز من نظام ملفات موقعة للقراءة فقط؛
• قم بتنفيذ التمهيد الآمن على أجهزتك، يقوم بتشغيل أداة تحميل التشغيل التي تفرض سلامة وسائط التمهيد؛
• ثق في أن الأشخاص في مؤسستك لن العبث باستخدام الأجهزة الخاصة بك.

الحصول على كل شيء صحيح هو المسعى الصعب. إنه لأبسط الكثير من العمل حوله من خلال تصميم نظامك بموجب نهج آخر:

• مستخدمي الحجر الصحي من النظام. لا تقم بتقديم الوسائل للمستخدمين لتنفيذ الأوامر على نظامك. تجنب القصف من داخل البرامج التي تعتمد على بيانات المستخدم.
• قم بتصميم إجراءات النشر الخاصة بك باستخدام إدارة التكوين والتأكد من أن عمليات النشر الخاصة بك "قابلة للتكرار"، مما يعني أنها تؤدي إلى نفس النتيجة الوظيفية عند نشرها عدة مرات. هذا يتيح لك "Nuke من المدار" الآلات التي تشك أنها تعرض للخطر.
• تعامل مع الأجهزة الخاصة بك كما لو كانت تتعرض للخطر: تشغيل عمليات التدقيق بانتظام للتحقق من سلامة أنظمتك. احفظ بياناتك على صور منفصلة وأنظمة إعادة النشر بانتظام. قم بتسجيل الصور ولديها أنظمة ترفض الصور غير الموقعة.
• استخدم الشهادات: لصالح نهج "تعليق الشهادات". قم بفك نشر شهادة جذر للتطبيقات الخاصة بك (والتي ستوفر الرفض التلقائي للتوقيعات التي لم يتم اعتمادها من قبل مؤسستك) ولكن على الأقل لديها نظام إدارة بصمات الصور الحالية وإعلام المسؤولين عند تغيير بصمات الأصابع. على الرغم من أنه من الممكن تنفيذ كل هذا باستخدام سلاسل المفاتيح، فقد تم تصميم المصادقة المستندة إلى الشهادات لهذا التطبيق الدقيق.

Answer 10

أحب أن أفكر في الأمن كسلسلة. يمكن أن يعرض الرابط الأضعف للسلسلة النظام بأكمله. لذلك أصبح الأمر كله "منع مستخدم غير مصرح به من الحصول على كلمة مرور الجذر".

كما اقترح deanmoulding مصدر البرنامج مهم أيضا وفي المستقبل ربما سيكون مخازن تطبيق نظام التشغيل الرسمي هو المعيار. فكر في Play Store أو Apple أو Microsoft Stores.

أعتقد أن تثبيت وتوزيع التعليمات البرمجية الضارة السرية هو مشكلة أكثر غدرا. بعد كل شيء، من أجل تحميل رمز سيء، يجب أولا تثبيته على النظام في مكان ما. عادة ما تكون طبقات الأمان أفضل عادة، بالطبع. السؤال هو: هل يستحق التكلفة؟

في رأيي، الجواب هو "ذلك يعتمد". يمكنك تقليل المخاطر من خلال اعتماد مجموعة من سياسات الأمان على النحو الذي اقترحته sleblanc. يمكنك تشفير نظام الملفات الخاص بك (https://en.wikipedia.org/wiki/linux_unified_key_setup.)، استخدم أنظمة الملفات للقراءة فقط للغينيوم أو استخدام آلية للتوقيع والتحقق من الثنائيات.

ومع ذلك، مهما كانت الآلية التي تستخدمها، لا يوجد شيء يمكنك القيام به بمجرد الحصول على وصول الجذر بواسطة مهاجم. يمكن استبدال أدوات التحقق من التوقيع بإصدار عطاء أو تعطيل فقط ولا يهم حقا إذا كانت الأدوات تعمل في مساحة المستخدم أو مساحة kernel مرة واحدة تعرضت للآلة للخطر (على الرغم من أن هذا الأخير سيكون أكثر أمانا بالطبع ).

لذلك سيكون من الرائع إذا كان يمكن أن يضم Kernel Linux وحدة التحقق من التوقيع وطبقة أمان أخرى بين مستخدم الجذر ونظام التشغيل.

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