लिनक्स

Question

के तहत निष्पादित निष्पादन योग्य सुरक्षा कारणों से, निष्पादन से पहले कोड की अखंडता की जांच करना वांछनीय है, किसी हमलावर द्वारा छेड़छाड़ किए गए सॉफ़्टवेयर से परहेज करना। तो, मेरा प्रश्न

निष्पादन योग्य कोड पर हस्ताक्षर कैसे करें और लिनक्स के तहत केवल विश्वसनीय सॉफ्टवेयर चलाएं?

मैंने वैन डूम एट अल के काम को पढ़ा है।, लिनक्स के लिए हस्ताक्षरित निष्पादन योग्यों के डिजाइन और कार्यान्वयन, और सैफर्ड & ज़ोहर द्वारा आईबीएम के TLC (विश्वसनीय लिनक्स क्लाइंट)। टीएलसी टीपीएम नियंत्रक का उपयोग करता है, क्या अच्छा है, लेकिन कागज 2005 से है और मैं वर्तमान विकल्पों को खोजने में असमर्थ था।

क्या आप एक और विकल्प जानते हैं?

अद्यतन: और अन्य ओएस के बारे में? ओपनसोलारिस? बीएसडी परिवार?

Answer 1

DigSig कर्नेल मॉड्यूल bsign नामक टूल द्वारा हस्ताक्षरित बाइनरी के सत्यापन लागू करता है। हालांकि, लिनक्स कर्नेल के संस्करण 2.6.21 के बाद से इस पर कोई काम नहीं किया गया है।

Answer 2

जीएनयू/लिनक्स/एफओएसएस मॉडल वास्तव में छेड़छाड़ को प्रोत्साहित करता है - एक प्रकार का। उपयोगकर्ता और डिस्ट्रो-निर्माता को अपनी जरूरतों के अनुसार सॉफ़्टवेयर को संशोधित करने के लिए स्वतंत्र होना चाहिए (सॉफ़्टवेयर)। कस्टमाइज़ेशन के लिए सॉफ़्टवेयर को पुन: संकलित करना (किसी भी स्रोत कोड को बदलने के बिना) कुछ ऐसा होता है जो अक्सर किया जाता है, लेकिन बाइनरी कोड-हस्ताक्षर तोड़ देगा। नतीजतन, बाइनरी कोड-हस्ताक्षर मॉडल जीएनयू/लिनक्स/एफओएसएस के लिए विशेष रूप से उपयुक्त नहीं है।

इसके बजाए, इस प्रकार का सॉफ़्टवेयर स्रोत संकुल के हस्ताक्षर और/या सुरक्षित हैंश उत्पन्न करने पर अधिक निर्भर करता है। एक भरोसेमंद और भरोसेमंद पैकेज वितरण मॉडल के संयोजन में, इसे बाइनरी कोड-साइनिंग के रूप में सुरक्षित (यदि अधिक नहीं है, तो स्रोत कोड में पारदर्शिता के साथ) के रूप में बनाया जा सकता है।

Answer 3

Medusa DS9 पर एक नज़र डालें। मैंने इसके साथ लंबे समय तक खेला (लंबा) समय पहले, लेकिन अगर मुझे सही याद है, तो आप विशिष्ट बाइनरी पंजीकृत कर सकते हैं और कर्नेल स्तर पर किसी भी संशोधन की अनुमति नहीं थी। बेशक, इसे मशीन तक स्थानीय पहुंच के साथ ओवरराइड किया जा सकता है, लेकिन यह वास्तव में आसान नहीं था। एक स्मार्ट डिमन है, जिसे कॉन्स्टेबल कहा जाता है, मशीन पर होने वाली हर चीज की जांच करता है और यदि सामान्य से कुछ बाहर होता है, तो यह चीखना शुरू कर देता है।

Answer 4

इस पर एक नज़र डालें: http://linux-ima.sourceforge.net/

यह अभी तक हस्ताक्षर करने नहीं कर रहा है, लेकिन यह अभी भी सत्यापन सक्षम बनाता है।

Answer 5

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

उपयोग एक PKCS7 (S/MIME) इसके बारे में संकेत। अपनी खुद की प्रमाणपत्र/निजी कुंजी जोड़ी उत्पन्न करें, प्रमाण पर स्वयं हस्ताक्षर करें और फिर अपनी फ़ाइल को निजी कुंजी और प्रमाण पत्र के साथ PKCS7 का उपयोग करके साइन करें। यह प्रमाण को संलग्न करेगा, और फिर यह openssl कमांड का उपयोग कर रनटाइम पर खुद को देख सकता है (मैन स्मेम या बस openssl मदद करता है)। यह tamperproof है क्योंकि भले ही सार्वजनिक कुंजी आपके द्वारा दी जाने वाली फ़ाइलों में है, फिर भी उस सार्वजनिक कुंजी के लिए S/MIME हस्ताक्षर केवल उस निजी कुंजी के साथ उत्पन्न किया जा सकता है जिसे आप वितरित नहीं करेंगे। इसलिए यदि आपके प्रमाण पत्र द्वारा फ़ाइल पर हस्ताक्षर किए गए हैं, तो इसे निजी कुंजी वाले किसी व्यक्ति द्वारा हस्ताक्षरित किया जाना चाहिए और चूंकि आपने किसी को निजी कुंजी नहीं दी है, तो यह आपके पास से आना चाहिए।

यहां स्वयं हस्ताक्षरित प्रमाणपत्र बनाने का तरीका बताया गया है।

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

आप openssl को समझाने के लिए (-CAfile) प्राधिकरण के एक रूट के रूप में अपने प्रमाणपत्र पर विश्वास करना है, तो रूट के रूप में उस के साथ यह जाँच, और भी प्रमाणपत्र की जांच पर फ़ाइल तुम्हारा है होगा (हैश प्रमाण) और हैश की जांच करें। ध्यान दें कि यद्यपि यह दस्तावेज नहीं है, ओपनएसएल की निकास स्थिति एक संकेत की पुष्टि करते समय आप जिस संकेत की जांच कर रहे हैं उसकी वैधता को दर्शाती है। यह 0 है अगर यह मेल खाता है, शून्य अगर शून्य नहीं है।

ध्यान दें कि यह सब सुरक्षित नहीं है क्योंकि यदि चेक आपके कोड में है, तो वे आसानी से चेक को हटा सकते हैं यदि वे आपको मारना चाहते हैं। ऐसा करने का एकमात्र सुरक्षित तरीका ओएस में चेकर रखना होगा और इसे अपनी बाइनरी जांचना होगा और अगर इसे हस्ताक्षरित नहीं किया जाता है तो उसे चलाने से इनकार कर दिया जाएगा। लेकिन चूंकि ओएस में कोई भी चेकर नहीं है और लिनक्स को इसे किसी भी तरह से हटाने/बाईपास करने के लिए संशोधित किया जा सकता है ... लोगों को बाईपास करने से रोकने के प्रयास में भ्रष्ट फ़ाइलों का पता लगाने के लिए यह वास्तव में अच्छा है।

Answer 6

मुझे एहसास है कि यह एक प्राचीन प्रश्न है लेकिन मुझे अभी यह मिला है।

मैंने कुछ समय पहले लिनक्स कर्नेल (संस्करण 2.4.3 के आसपास) के लिए निष्पादन योग्य समर्थन लिखा था, और execve(2) समय पर हस्ताक्षर की जांच करने के लिए पूरे टूलचेन को हस्ताक्षर किया था, हस्ताक्षर सत्यापन जानकारी को कैश करना (साफ़ करना सत्यापन जब फ़ाइल को लिखने के लिए खोला गया था या अन्यथा संशोधित किया गया था), मनमानी ईएलएफ कार्यक्रमों में हस्ताक्षर एम्बेड करना आदि। इसने प्रत्येक कार्यक्रम के पहले निष्पादन पर कुछ प्रदर्शन दंड प्रस्तुत किए थे (क्योंकि कर्नेल को संपूर्ण फ़ाइल में लोड करना पड़ा था, केवल आवश्यक पृष्ठों की मांग पृष्ठ की बजाय) लेकिन एक बार सिस्टम एक स्थिर स्थिति में था, यह अच्छी तरह से काम किया। पर हस्ताक्षर किए पुस्तकालयों के लिए

• हम अभी तक निर्माण नहीं किया था समर्थन:

  लेकिन हम यह पीछा क्योंकि यह कई समस्याओं कि जटिलता का औचित्य साबित करने के लिए बहुत बड़ी थे सामना करना पड़ा बंद करने का फैसला। हस्ताक्षरित पुस्तकालयों को ld.so लोडर और dlopen(3) तंत्र को संशोधित करने की आवश्यकता होगी। यह असंभव नहीं था लेकिन इंटरफ़ेस को जटिल बना दिया: क्या हमारे पास लोडर को कर्नेल से हस्ताक्षर को सत्यापित करने के लिए कहा जाना चाहिए या गणना पूरी तरह से उपयोगकर्तास्थान में पूरी की जानी चाहिए? यदि उपयोगकर्ता स्पेस में सत्यापन का यह हिस्सा किया जाता है तो strace(2) डी प्रक्रिया के विरुद्ध कोई कैसे सुरक्षा करेगा? क्या हमें पूरी तरह से ऐसी प्रणाली पर strace(2) को मना करने के लिए मजबूर होना होगा?

  हम programs that supply their own loader के बारे में क्या करेंगे?

• ईएलएफ वस्तुओं को संकलित नहीं करने वाली भाषाओं में बहुत से कार्यक्रम लिखे गए हैं। हम bash, perl, python, java, awk, sed, और इतने पर, दुभाषियों के प्रत्येक होने के लिए सक्षम करने के लिए भी सत्यापित हस्ताक्षर करने के लिए भाषा-विशिष्ट संशोधनों प्रदान करने के लिए की आवश्यकता होगी। चूंकि इनमें से अधिकतर प्रोग्राम फ्री-फॉर्मेट सादा पाठ हैं, इसलिए वे उस संरचना की कमी करते हैं जिसने ईएलएफ ऑब्जेक्ट फ़ाइलों में डिजिटल हस्ताक्षर को इतना आसान बना दिया है। हस्ताक्षर कहाँ संग्रहित किया जाएगा? स्क्रिप्ट में? विस्तारित विशेषताओं में? हस्ताक्षर के बाहरी डेटाबेस में?

• कई दुभाषिया चौड़े खुले हैं जो वे अनुमति देते हैं; bash(1) रिमोट सिस्टम पूरी तरह से अपने पर echo और /dev/tcp का उपयोग कर संवाद कर सकता है, और किसी भी हमलावर की ज़रूरतों को निष्पादित करने में आसानी से धोखा दिया जा सकता है। हस्ताक्षर किए या नहीं, एक बार जब वे हैकर के नियंत्रण में थे तो आप उन पर भरोसा नहीं कर सके।

• पर हस्ताक्षर किए निष्पादनयोग्य समर्थन के लिए प्रमुख प्रेरक की जगह रूटकिट से आता है प्रणाली के द्वारा उपलब्ध कराया इतने पर /bin/ps, /bin/ps, /bin/kill, और। हां, एक्जिक्यूटिव पर हस्ताक्षर करने के अन्य उपयोगी कारण हैं। हालांकि, रूटकिट्स समय के साथ काफी प्रभावशाली हो गए हैं, जिनमें से कई कर्नेल हैक पर प्रशासकों से अपनी गतिविधियों को छिपाने के लिए हैं। एक बार कर्नेल को हैक कर दिया गया है, पूरा खेल खत्म हो गया है। रूटकिट्स के परिष्कार के परिणामस्वरूप जिन उपकरणों को हम इस्तेमाल करने से रोकने की उम्मीद कर रहे थे, वे हैकिंग समुदाय में पक्षपात से बाहर हो रहे थे।

• कर्नेल का मॉड्यूल लोडिंग इंटरफ़ेस व्यापक रूप से खुला था। एक बार प्रक्रिया में root विशेषाधिकार है, तो बिना किसी जांच के कर्नेल मॉड्यूल को इंजेक्ट करना आसान था। हम कर्नेल मॉड्यूल के लिए एक और सत्यापनकर्ता भी लिख सकते थे लेकिन मॉड्यूल के आसपास कर्नेल का बुनियादी ढांचा बहुत ही प्राचीन था।

Answer 7

मैंने कभी कोशिश नहीं की है, लेकिन इसे देखें: http://blog.codenoise.com/signelf-digitally-signing-elf-binaries। समाधान कर्नेल समर्थन की आवश्यकता के बिना काम करता है, और ऐसा लगता है कि जाने के लिए तैयार होना पसंद है।

हस्ताक्षरकर्ता के लिए कोड http://sourceforge.net/projects/signelf/

यह सवाल "केवल भागो लिनक्स पर भरोसा कोड" का समाधान नहीं करता पर पाया जा सकता है, लेकिन यह आंशिक रूप से कार्यक्रम में ही पता लगाने के लिए एक तरह से बनाने के द्वारा समस्या को हल करता है एक संभावित छेड़छाड़/भ्रष्टाचार

Answer 8

मैं सोलारिस 10 & 11 ओएस परिप्रेक्ष्य से प्रश्न का उत्तर दे सकता हूं, सभी बाइनरी हस्ताक्षरित हैं। '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. 

ओरेकल हाल ही में सोलारिस 11 के लिए एक सत्यापित बूट प्रक्रिया भी जोड़ लिया है के विवरण देखें - Solaris Verified Boot Introduction

ओपनसोलारिस कोड के कुछ उत्पादन ग्रेड कांटे हैं , इलुमोस, स्मार्टओएस और ओमनीओस की जांच के तीन मूल्य हैं।