क्या कोई शेल है जो यह सुनिश्चित करने के लिए जांचता है कि कोड पर हस्ताक्षर किए गए हैं?

Question

मैं इस सप्ताह पॉवरशेल के साथ गड़बड़ कर रहा था और पता चला कि आपको अपनी स्क्रिप्ट पर हस्ताक्षर करने की आवश्यकता है ताकि उन्हें चलाया जा सके। क्या लिनक्स में कोई समान सुरक्षित कार्यक्षमता है जो बैश स्क्रिप्ट को चलाने से रोकने से संबंधित है?

इस तरह की एकमात्र कार्यक्षमता, जो मुझे पता है कि एसएसएच एक निश्चित कुंजी की आवश्यकता है।

Comments

मेरे लिए हस्ताक्षर करने के लिए एक तदर्थ समाधान की तरह एक सा लगता है। मुझे नहीं पता कि विंडोज में क्रिप्टोग्राफिक पैकेज है जिस तरह से लिनक्स पर हस्ताक्षर है।

— वाइल्डकार्ड

@ leeand00 एक स्क्रिप्ट एक सॉफ्टवेयर पैकेज का एक विशेष मामला है और मैं उस मामले को एकल करने के लिए कोई बिंदु नहीं देख सकता।

— गिल्स एसओ- बुराई को रोकना '

जिस तंत्र में मैं सबसे ज्यादा शौकीन हूं, वह यह है कि क्रोमोस ऐसा करता है - केवल फाइल सिस्टम को फ्लैग नहीं noexecकिया जाता है केवल एक डीएम-वेरिटी हस्ताक्षरित ब्लॉक डिवाइस पर रीड-ओनली विभाजन पर।

— चार्ल्स डफी

source.android.com/security/verifiedboot Android के उस (पहले ChromeOS) फ़ीचर को अपनाने की बात करता है।

— चार्ल्स डफी

आप कमांड लाइन इंटरफेस में मैन्युअल टाइप किए जा सकने वाले कमांड के एक समूह के रूप में बैश पर विचार कर सकते हैं। जब आप कमांड लाइन में सामग्री को टाइप कर सकते हैं तो स्क्रिप्ट को प्रतिबंधित करने का क्या मतलब है?

— डिंग-यी चेन

Answer 1

यदि आप उपयोगकर्ताओं को स्क्रिप्ट चलाने की क्षमता लॉक कर रहे हैं sudoतो आप digestकार्यक्षमता का उपयोग कर सकते हैं ।
आप एक स्क्रिप्ट / निष्पादन योग्य के हैश को निर्दिष्ट कर सकते हैं sudoersजिसमें sudoनिष्पादित होने से पहले सत्यापित किया जाएगा । इसलिए यद्यपि हस्ताक्षर करने के समान नहीं है, यह आपको एक बुनियादी गारंटी देता है कि स्क्रिप्ट को कम से कम संशोधित नहीं किया गया है बिना sudoers भी संशोधित किया जा रहा है।

यदि कोई कमांड नाम Digest_Spec के साथ उपसर्ग करता है, तो कमांड केवल तभी सफलतापूर्वक मेल खाएगा यदि यह निर्दिष्ट SHA-2 डाइजेस्ट का उपयोग करके सत्यापित किया जा सकता है। यह उन स्थितियों में उपयोगी हो सकता है, जहां उपयोगकर्ता सूडो को कमांड या इसके मूल निर्देशिका तक पहुंच लिखता है। निम्नलिखित पाचन प्रारूप समर्थित हैं: sha224, sha256, sha384 और sha512। स्ट्रिंग को हेक्स या बेस 64 प्रारूप में निर्दिष्ट किया जा सकता है (बेस 64 अधिक कॉम्पैक्ट है)। कई उपयोगिताओं में हेक्स प्रारूप में SHA-2 डाइजेस्ट बनाने में सक्षम हैं जैसे कि ओपनसीएल, श्सम, sha224sum, sha256sum, sha384sum, sha512sum।

http://www.sudo.ws/man/1.8.13/sudoers.man.html

Comments

जब तक मैं एसई लिनक्स के बारे में नहीं पढ़ूंगा और इसे सही करूंगा, तब तक मुझे पकड़ लेंगे।

— leeand00

Answer 2

हां और ना।

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

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

ऐसा कोई विशेष तंत्र नहीं है जो सॉफ्टवेयर पैकेजों को एकल करता है जिसमें सॉफ्टवेयर पैकेजों से एकल स्क्रिप्ट शामिल होती है जिसमें एक देशी निष्पादन योग्य, एक डेटा फ़ाइल, या कई फाइलें शामिल होती हैं। न ही किसी भी सामान्य स्क्रिप्ट दुभाषिया में कोई हस्ताक्षर सत्यापन बनाया गया है, क्योंकि किसी सॉफ्टवेयर पैकेज की पुष्टि करना स्क्रिप्ट चलाने से पूरी तरह से ओर्थोगोनल चिंता है।

मुझे लगता है कि विंडोज ने अपने मूल के साथ फाइलें एनोटेट की हैं, और एक फाइल चलाने के लिए उपयोगकर्ता की पुष्टि की आवश्यकता होती है, जिसका मूल "स्थानीय" के बजाय "डाउनलोड" है। लिनक्स वास्तव में एक समान तंत्र नहीं है। निकटतम चीज निष्पादन की अनुमति है: डाउनलोड की गई फ़ाइल में निष्पादन की अनुमति नहीं है, उपयोगकर्ता को इसे स्पष्ट रूप से सक्षम करने की आवश्यकता है ( chmod +xकमांड लाइन पर, या फ़ाइल प्रबंधक में समकक्ष कार्रवाई)।

Comments

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

— स्टीफन हैरिस

@StephenHarris ठीक है अगर आप इसे बाईपास पर सेट करते हैं ...

— leeand00

@ leeand00 - जाहिरा तौर पर base64 एन्कोडिंग भी बाईपास के रूप में काम करता है लेकिन मुझे नहीं पता कि पॉवरहेल के नए संस्करणों में बंद किया गया है या नहीं।

— स्टीफन हैरिस

@ leeand00 - darkoperator.com/blog/2013/3/5/… कुछ मज़े के लिए देखें :: मूल रूप से कमांड लाइन पर एक पैरामीटर के रूप में बेस 64 एनकोडेड स्क्रिप्ट पास करें :-) रैपर के लिए काफी आसान है!

— स्टीफन हैरिस

SeLinux ने अपने मूल के साथ फाइलें एनोटेट कीं। यह इसके मुख्य परिसरों में से एक है।

— loa_in_

Answer 3

लिनक्स डिजिटल हस्ताक्षर के आधार पर बैश स्क्रिप्ट के निष्पादन को सीमित करने की क्षमता प्रदान नहीं करता है।

द्विआधारी निष्पादन योग्य को प्रमाणित करने पर कुछ काम है। जानकारी के लिए https://lwn.net/Articles/488906/ देखें ।

Comments

एक हैके काम के आसपास का सुझाव दिए बिना सीधे जवाब के लिए अपवोट।

— user394

Answer 4

एक शब्द में, "नहीं"।

लिनक्स निष्पादन योग्य और स्क्रिप्ट के बीच वास्तव में अंतर नहीं करता है; #!शुरुआत में एक तरह से गिरी क्या कार्यक्रम इनपुट मूल्यांकन करने के लिए चलाने के लिए बताने के लिए है, लेकिन यह एक ही तरीका है एक स्क्रिप्ट निष्पादित किया जा सकता है।

इसलिए, उदाहरण के लिए, यदि मेरे पास एक स्क्रिप्ट है

$ cat x
#!/bin/sh 
echo hello

फिर मैं इसे कमांड से चला सकता हूं

$ ./x

यह कर्नेल को प्रयास करने और उस पर अमल करने का कारण बनेगा, #!और फिर /bin/sh xइसके बजाय प्रभावी ढंग से चलाएं ।

हालाँकि मैं इनमें से किसी भी प्रकार को भी चला सकता था :

$ sh ./x
$ bash ./x
$ cat x | sh
$ cat x | bash
$ sh < x

या और भी

. ./x

तो भले ही कर्नेल ने execपरत पर हस्ताक्षर को लागू करने की कोशिश की हो, हम इसे केवल एक पैरामीटर के रूप में स्क्रिप्ट के साथ दुभाषिया चलाकर बाईपास कर सकते हैं।

इसका मतलब है कि हस्ताक्षर कोड को दुभाषिया में ही होना चाहिए। और क्या कोई उपयोगकर्ता हस्ताक्षर प्रवर्तन कोड के बिना किसी शेल की अपनी प्रति को संकलित करने से रोक सकता है ?

इसके मानक समाधान पर हस्ताक्षर का उपयोग नहीं करना है, लेकिन अनिवार्य अभिगम नियंत्रण (मैक) का उपयोग करना है, जैसे कि SELinux। मैक सिस्टम के साथ आप यह निर्दिष्ट कर सकते हैं कि प्रत्येक उपयोगकर्ता को परतों को चलाने और संक्रमण करने की अनुमति क्या है। इसलिए, उदाहरण के लिए, आप कह सकते हैं "सामान्य उपयोगकर्ता कुछ भी चला सकते हैं लेकिन वेब सर्वर और CGI प्रक्रियाएं केवल /var/httpdनिर्देशिका से सामान एक्सेस कर सकती हैं , बाकी सब अस्वीकार कर दिया गया है"।

Comments

This means that signing code would have to be in the interpreter itself. And what would stop a user from compiling their own copy of a shell without the signing enforcement code?किसी भी अहस्ताक्षरित निष्पादक को निष्पादित करने की अनुमति नहीं है, यदि उपयोगकर्ता के पास हस्ताक्षर करने की कुंजी नहीं है। इसके लिए पहले से विभिन्न * निक्स परियोजनाएं हैं।

— alzee

Answer 5

लिनक्स डिस्ट्रोस में आमतौर पर gnupg होता है । यह मुझे लगता है जैसे आप चाहते हैं कि एक साधारण बैश रैपर है जो तर्क स्क्रिप्ट के खिलाफ एक अलग gpg हस्ताक्षर की जांच करता है और केवल चेक को सफल होने पर स्क्रिप्ट को चलाने के लिए आगे बढ़ता है:

#!/bin/sh
gpgv2 $1.asc && bash "$@"

Comments

केवल यही चीज मौजूद नहीं है एक स्क्रिप्ट चल रही है जिसे किसी ने अभी बनाया है ... अपने दम पर ...

— leeand00

Answer 6

तुरंत दिमाग में आने वाला जवाबी सवाल यह है कि "आप कभी भी उपयोगकर्ताओं को उनके लिखे प्रोग्राम चलाने से क्यों रोकना चाहेंगे ? " कई संभावनाएँ मौजूद हैं

1. यह पता लगाना असंभव है कि पहली जगह में कोड किसने लिखा था। स्क्रिप्ट फ़ाइल का स्वामी केवल वह है जो वास्तव में उस फ़ाइल की सामग्री को सहेजता है, भले ही वह कहाँ से आई हो। इसलिए एक हस्ताक्षर लागू करना पुष्टि संवाद बॉक्स के लिए सिर्फ एक जटिल विकल्प है: "क्या आप सुनिश्चित हैं कि आप ऐसा करना चाहते हैं?" लिनक्स में इस समस्या को पारदर्शी रूप से हस्ताक्षरित पैकेजों के साथ हल किया जाता है, और इस तथ्य से कम किया जाता है कि उपयोगकर्ता डिफ़ॉल्ट रूप से सीमित पहुंच रखते हैं। उपयोगकर्ता को यह भी जानने की उम्मीद है कि दूसरों का कोड चलाना खतरनाक हो सकता है *।
2. एक ही नस में एक स्क्रिप्ट पर हस्ताक्षर एक फ़ाइल को बचाने की तुलना में बहुत अधिक जटिल ऑपरेशन है। सबसे अच्छे मामले में यह उपयोगकर्ता को यह महसूस करने के लिए प्रेरित करता है कि वे एक दस्तावेज़ पर हस्ताक्षर करने के समान कार्रवाई कर रहे हैं, और निरीक्षण करना चाहिए कि इसे जारी रखने से पहले क्या कहते हैं। सबसे अधिक संभावना है कि यह स्क्रिप्ट को चलाने के लिए उपयोगकर्ता की ओर से तकनीकी दक्षता का एक बहुत ही न्यूनतम स्तर सुनिश्चित करता है । सबसे खराब स्थिति में यह हुप्स की एक लंबी श्रृंखला के माध्यम से कूदने की इच्छा को प्रदर्शित करता है जो वे चाहते थे। तकनीकी प्रवीणता लिनक्स * पर ग्रहण की जाती है।
3. यह अधिक संभावना है कि लोग अपनी कमांड लाइन पर कमांड की एक श्रृंखला टाइप / पेस्ट करते समय स्पष्ट रूप से दुर्भावनापूर्ण कोड का पता लगाएंगे । प्लेनटेक्स्ट स्निपेट का मतलब होता है नकल करना और चिपकाया जाना आमतौर पर कुछ ठीक से नापाक करने के लिए आवश्यक आदेशों की श्रृंखला से छोटा होता है। उपयोगकर्ता हर पंक्ति को सावधानीपूर्वक कॉपी और पेस्ट कर सकता है, यह समझने के लिए कि क्या होता है। एक स्क्रिप्ट के साथ यह संभव है कि उपयोगकर्ता ने कभी भी कोड को नहीं देखा हो। यह हस्ताक्षरित लिपियों का एक उपयोगी अनुप्रयोग हो सकता है, 12 वीं बार के बाद शालीनता की सभी-सामान्य लागत पर।

* यह शायद कम और कम सच होता जा रहा है क्योंकि अधिक लोग लिनक्स का उपयोग करना शुरू करते हैं

Answer 7

सिस्टम के अलग-अलग रूप से विकसित होने का कारण यह है कि लिनक्स में 'एक्जीक्यूटिव' फ़ाइल विशेषता है और विंडोज़ निष्पादन को निर्धारित करने के लिए फ़ाइल एक्सटेंशन का उपयोग करता है।

इसलिए विंडोज में उपयोगकर्ता को ".exe", ".bat", ".scr" एक्सटेंशन के साथ फ़ाइल डाउनलोड करने में ट्रिक करना आसान है, जो डिफ़ॉल्ट रूप से छिपा होगा । उस फ़ाइल को डबल-क्लिक करने से आपको मध्यस्थ कोड निष्पादन मिलेगा। इसलिए इस जोखिम को कम करने के लिए मूल ट्रैकिंग और निष्पादन योग्य / स्क्रिप्ट हस्ताक्षर का एक बड़ा तंत्र बनाया गया था।

लिनक्स पर, आप उपयोगकर्ता के लिए एक फ़ाइल प्राप्त करने में सक्षम हो सकते हैं, लेकिन आप आसानी से 'निष्पादित' बिट को सेट करने के लिए मजबूर नहीं कर सकते। इसके अतिरिक्त, पूरे फाइलसिस्टम को 'नोएसेक' बनाना संभव है।

आप किसी भी मामले में दुभाषिया को आमंत्रित करके एक स्क्रिप्ट को स्पष्ट रूप से चला सकते हैं। आप रनटाइम पर शेल स्क्रिप्ट भी बना सकते हैं और उन्हें "श" में पाइप कर सकते हैं, या "श-सी" चला सकते हैं।

Answer 8

कस्टम रूप से, कई संग्रह कार्यक्रम निहित फ़ाइलों पर निष्पादित बिट को संरक्षित नहीं करते हैं। इससे मनमानी निष्पादन को चलाना असंभव हो जाता है। हां तकरीबन।

मुद्दा यह है कि एक अन्य जवाब में क्या वर्णित किया गया था कि निष्पादित बिट की कमी आपको इस तरह की स्क्रिप्ट को सीधे पारित करने से नहीं रोकती है bash। हालांकि यह तर्कपूर्ण है कि इस तरह की अधिकांश स्क्रिप्ट स्क्रिप्ट हैं bash, शेबबैंग किसी भी कार्यक्रम को दुभाषिया के रूप में निर्दिष्ट कर सकता है। इसका मतलब यह है कि यदि उचित निष्पादन को नजरअंदाज करने का निर्णय लेते हैं तो उपयोगकर्ता को उचित दुभाषिया चलाना है।

हालांकि यह ज्यादा नहीं है, यह बहुत ज्यादा कर्नेल और शेल के साथ * निक्स पर अविश्वासी निष्पादनयोग्य को चलाने से रोकता है ।

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

तो, अंत में यह सामान्य रूप से प्रीइंस्टॉल्ड टूल के कॉन्फ़िगरेशन की बात है, और इसका उत्तर हां है ।

Comments

कई संग्रह कार्यक्रम निहित फ़ाइलों पर बिट निष्पादित नहीं करते हैं .. ठीक है, यह एक बाधा की तरह है जब आप वास्तव में संग्रह के साथ इसका उपयोग करना चाहते हैं। सौभाग्य से निष्पादित बिट tar को संरक्षित करता है।

— pjc50

आपको tar -p

— loa_in_

-p, --preserve-permissions, --same-permissionsमतलब फ़ाइल अनुमतियों के बारे में जानकारी निकालना (

— सुपरयुजर के

नहीं, आपको -p की आवश्यकता नहीं है। मैं देखता हूं कि मैन पेज क्या कहता है, लेकिन ऐसा नहीं होता है। touch permtest; chmod +x permtest; tar cf permtest.tar.gz permtest; rm permtest; tar xf permtest.tar.gz; ls -l permtest- यह यहाँ निष्पादन योग्य है, और मैं जड़ नहीं हूँ।

— व्यक्त करते

मैं तब अपना उत्तर सुधारने का प्रयास करूँगा।

— लो___