शेल स्क्रिप्ट पर सेट्यूड की अनुमति दें

184

setuidअनुमति सा लिनक्स बताता निष्पादक के बजाय मालिक के प्रभावी प्रयोक्ता आईडी के साथ एक कार्यक्रम चलाने के लिए:

> cat setuid-test.c

#include <stdio.h>
#include <unistd.h>

int main(int argc, char** argv) {
    printf("%d", geteuid());
    return 0;
}

> gcc -o setuid-test setuid-test.c
> ./setuid-test

1000

> sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test
> ./setuid-test

65534

हालाँकि, यह केवल निष्पादनों पर लागू होता है; शेल स्क्रिप्ट सेट्युइट बिट को अनदेखा करती हैं:

> cat setuid-test2

#!/bin/bash
id -u

> ./setuid-test2

1000

> sudo chown nobody ./setuid-test2; sudo chmod +s ./setuid-test2
> ./setuid-test2

1000

विकिपीडिया कहता है :

सुरक्षा खामियों की बढ़ती संभावना के कारण, कई ऑपरेटिंग सिस्टम निष्पादन योग्य शेल स्क्रिप्ट पर लागू होने पर सेटिड विशेषता को अनदेखा करते हैं।

यह मानते हुए कि मैं उन जोखिमों को स्वीकार करने के लिए तैयार हूं, क्या लिनक्स को शेल स्क्रिप्ट पर उसी तरह से व्यवहार करने का कोई तरीका है जैसा कि यह निष्पादन योग्यताओं पर करता है?

यदि नहीं, तो क्या इस समस्या के लिए एक आम समाधान है? मेरा वर्तमान समाधान यह है कि किसी दिए गए स्क्रिप्ट को चलाने के sudoersलिए एक प्रविष्टि जोड़ने के लिए, ALLजैसा कि मैं चाहता हूं कि उपयोगकर्ता इसे चलाए, NOPASSWDपासवर्ड प्रॉम्प्ट से बचने के लिए। मुख्य गिरावट यह है कि sudoersमुझे ऐसा करने के लिए हर बार एक प्रविष्टि की आवश्यकता है, और sudo some-scriptइसके बजाय कॉल करने वाले की आवश्यकता हैsome-script

— माइकल Mrozek
स्रोत

202

लिनक्स सभी व्याख्या किए गए निष्पादनों (यानी एक #!पंक्ति से शुरू होने वाले निष्पादनयोग्य ) पर सेतु के बिट को अनदेखा करता है । Comp.unix.questions पूछे जाने वाले प्रश्न setuid शेल स्क्रिप्ट की सुरक्षा संबंधित समस्याओं बताते हैं। ये समस्याएं दो प्रकार की होती हैं: शेबंग-संबंधी और शेल-संबंधित; मैं नीचे अधिक विवरण में जाता हूं।

यदि आप सुरक्षा के बारे में परवाह नहीं करते हैं और लिनक्स के तहत सेटिड स्क्रिप्ट की अनुमति देना चाहते हैं, तो आपको कर्नेल को पैच करना होगा। 3.x कर्नेल के रूप में, मुझे लगता है कि आपको कॉल करने install_exec_credsसे load_scriptपहले फ़ंक्शन में कॉल जोड़ने की आवश्यकता है open_exec, लेकिन मैंने परीक्षण नहीं किया है।

सेतुबंध शबंग

#!आमतौर पर शबंग ( ) को लागू करने के लिए एक दौड़ की स्थिति निहित है :

कर्नेल निष्पादन योग्य खोलता है, और पाता है कि यह इसके साथ शुरू होता है #!।
कर्नेल निष्पादन योग्य बंद कर देता है और दुभाषिया खोलता है।
कर्नेल स्क्रिप्ट को तर्क सूची (एस argv[1]) के लिए पथ सम्मिलित करता है , और दुभाषिया को निष्पादित करता है।

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

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

कुछ यूनिक्स सिस्टम (मुख्य रूप से ओपनबीएसडी, नेटबीएसडी और मैक ओएस एक्स, जिनमें से सभी को कर्नेल सेटिंग को सक्षम करने की आवश्यकता होती है) एक अतिरिक्त सुविधा का उपयोग करके सुरक्षित सेतुंग को लागू करें : पथ फ़ाइल डिस्क्रिप्टर एन पर पहले से खोली गई फ़ाइल को संदर्भित करता है (इसलिए उद्घाटन है) लगभग बराबर )। कई यूनिक्स सिस्टम (लिनक्स सहित) में स्क्रिप्ट सेट नहीं है।/dev/fd/N/dev/fd/Ndup(N)/dev/fd

कर्नेल निष्पादन योग्य खोलता है, और पाता है कि यह इसके साथ शुरू होता है #!। मान लें कि निष्पादन योग्य के लिए फ़ाइल विवरणक 3 है।
कर्नेल दुभाषिया खोलता है।
कर्नेल /dev/fd/3तर्क सूची (जैसा argv[1]) को सम्मिलित करता है , और दुभाषिया को निष्पादित करता है।

स्वेन मस्कैच के शेबबैंग पेज में यूनियनों के बारे में बहुत सारी जानकारी है, जिसमें सेतु समर्थन भी शामिल है ।

सेतुवाद व्याख्याकार

मान लें कि आप अपने प्रोग्राम को रूट के रूप में चलाने में कामयाब रहे हैं, क्योंकि या तो आपका ओएस सेट्युड शेबेंग का समर्थन करता है या क्योंकि आपने एक देशी बाइनरी आवरण (जैसे कि sudo) का उपयोग किया है। क्या आपने सुरक्षा छेद खोला है? हो सकता है । यहाँ समस्या बनाम संकलित कार्यक्रमों की व्याख्या नहीं है। मुद्दा यह है कि क्या आपका रनटाइम सिस्टम विशेषाधिकारों के साथ निष्पादित होने पर सुरक्षित व्यवहार करता है।

किसी भी गतिशील रूप से जुड़े देशी बाइनरी निष्पादन योग्य एक तरह से गतिशील लोडर (जैसे /lib/ld.so) द्वारा व्याख्या की जाती है , जो प्रोग्राम द्वारा आवश्यक गतिशील पुस्तकालयों को लोड करता है। कई यूनियनों पर, आप पर्यावरण के माध्यम से गतिशील पुस्तकालयों के लिए खोज पथ को कॉन्फ़िगर कर सकते हैं ( LD_LIBRARY_PATHपर्यावरण चर के लिए एक सामान्य नाम है), और यहां तक कि सभी निष्पादित बायनेरिज़ ( LD_PRELOAD) में अतिरिक्त पुस्तकालयों को लोड करें । कार्यक्रम के हमलावर को विशेष रूप से तैयार की libc.soगई $LD_LIBRARY_PATH(अन्य रणनीति के बीच) रखकर उस कार्यक्रम के संदर्भ में मनमाना कोड निष्पादित किया जा सकता है । सभी समझदार सिस्टम LD_*सेतु निष्पादन में चर को अनदेखा करते हैं ।
में गोले ऐसे श, csh और डेरिवेटिव के रूप में, वातावरण चर स्वचालित रूप से खोल पैरामीटर बन जाते हैं। जैसे मानकों के माध्यम से PATH, IFS, और कई और अधिक, स्क्रिप्ट की invoker शेल स्क्रिप्ट के संदर्भ में मनमाने ढंग से कोड निष्पादित करने के लिए कई अवसर हैं। कुछ गोले इन चरों को सेट करने के लिए डिफॉल्ट करते हैं यदि वे पता लगाते हैं कि स्क्रिप्ट को विशेषाधिकारों के साथ लागू किया गया है, लेकिन मुझे नहीं पता कि कोई विशेष कार्यान्वयन है जिस पर मुझे भरोसा होगा।
अधिकांश रनटाइम वातावरण (चाहे मूल, बाइटकोड या व्याख्या की गई) में समान विशेषताएं हैं। कुछ लोग सेतु के निष्पादन में विशेष सावधानी बरतते हैं, हालांकि देशी कोड चलाने वाले अक्सर डायनेमिक लिंकिंग (जो सावधानी बरतते हैं) की तुलना में कुछ भी नहीं करते हैं।
पर्ल एक उल्लेखनीय अपवाद है। यह स्पष्ट रूप से एक सुरक्षित तरीके से सेतु लिपियों का समर्थन करता है । वास्तव में, आपकी स्क्रिप्ट सेटिउड चला सकती है, भले ही आपके ओएस ने स्क्रिप्ट पर सेट बिट को अनदेखा किया हो। इसका कारण यह है कि एक सेटलिड रूट हेल्पर के साथ पर्ल जहाज जो आवश्यक जांच करता है और वांछित विशेषाधिकारों के साथ वांछित स्क्रिप्ट पर दुभाषिया को फिर से स्थापित करता है। यह पर्ल्सेक मैनुअल में समझाया गया है । ऐसा लगता है कि सेतु पर्ल लिपियों के #!/usr/bin/suidperl -wTबजाय की जरूरत है #!/usr/bin/perl -wT, लेकिन अधिकांश आधुनिक प्रणालियों पर, #!/usr/bin/perl -wTपर्याप्त है।

ध्यान दें कि इन समस्याओं को रोकने के लिए देशी बाइनरी रैपर का उपयोग करना अपने आप में कुछ नहीं है । वास्तव में, यह स्थिति को बदतर बना सकता है, क्योंकि यह आपके रनटाइम वातावरण को यह पता लगाने से रोक सकता है कि यह विशेषाधिकारों के साथ लगाया गया है और इसके रनटाइम कॉन्फ़िगरेशन को दरकिनार कर सकता है।

एक देशी बाइनरी रैपर एक शेल स्क्रिप्ट को सुरक्षित बना सकता है यदि आवरण पर्यावरण को सुरक्षित करता है । स्क्रिप्ट का ध्यान रखना चाहिए कि बहुत अधिक धारणाएं न बनें (उदाहरण के लिए वर्तमान निर्देशिका के बारे में) लेकिन ऐसा होता है। आप इसके लिए sudo का उपयोग कर सकते हैं बशर्ते कि यह पर्यावरण को साफ करने के लिए स्थापित हो। ब्लैकलिस्टिंग वैरिएबल त्रुटि-प्रवण है, इसलिए हमेशा श्वेतसूची। सुडो के साथ, सुनिश्चित करें कि env_resetविकल्प चालू है, वह setenvबंद है, और वह env_fileऔर env_keepकेवल सहज चर हैं।

टी एल, डी आर:

सैट्यूड शेबंग असुरक्षित है लेकिन आमतौर पर इसे नजरअंदाज कर दिया जाता है।
यदि आप विशेषाधिकारों (या तो sudo या setuid के माध्यम से) के साथ कोई प्रोग्राम चलाते हैं, तो मूल कोड या पर्ल लिखें, या प्रोग्राम को एक रैपर से शुरू करें जो पर्यावरण को साफ करता है (जैसे कि env_resetविकल्प के साथ sudo )।

¹ _{इस चर्चा समान रूप से लागू करता है, तो आप "setgid" "setuid" के लिए स्थानापन्न; वे दोनों स्क्रिप्ट पर लिनक्स कर्नेल द्वारा नजरअंदाज कर रहे हैं}

— गाइल्स
स्रोत

2

@ जोश: सुरक्षित सेयुड शेल स्क्रिप्ट संभव है, लेकिन केवल तभी जब शेल कार्यान्वयनकर्ता और स्क्रिप्ट लेखक दोनों बहुत सावधान रहें। मूल कोड के बजाय, मैं पर्ल की सलाह देता हूं, जहां कार्यान्वयनकर्ताओं ने ध्यान रखा है कि स्क्रिप्ट लेखक के हिस्से पर थोड़ी मेहनत के साथ सेतु लिपियों को सुरक्षित किया जाना चाहिए।

— गिल्स

3

जाहिरा तौर पर suidperlसामान को हटा दिया गया है और वर्षों के लिए हटाने के लिए चिह्नित किया गया है (लेकिन गैर-कम रहता है)

— jmtd

7

वास्तव suidperlमें perl 5.11 (5.12 स्थिर): perl5110delta:> "suidperl" के रूप में हटा दिया गया है। यह सिस्टम पर सेटिड अनुमति बिट्स का अनुकरण करने के लिए एक तंत्र प्रदान करता था जो इसे ठीक से समर्थन नहीं करते हैं। perl5120delta:> "suidperl" अब Perl का हिस्सा नहीं है। यह सिस्टम पर सेटिड अनुमति बिट्स का अनुकरण करने के लिए एक तंत्र प्रदान करता था जो इसे ठीक से समर्थन नहीं करते हैं।

— रैंडी स्टैनर

5

पर्ल 5.6.1 डॉक्स (लगभग एक दशक पहले) से इस लाइन पर भी ध्यान दें ... perl561delta:> ध्यान दें कि suidperl पर्ल के किसी भी हाल के संस्करण में डिफ़ॉल्ट रूप से न तो बनाया गया है और न ही स्थापित किया गया है। Suidperl का उपयोग अत्यधिक हतोत्साहित किया जाता है । अगर आपको लगता है कि आपको इसकी आवश्यकता है, तो पहले sudo जैसे विकल्पों का प्रयास करें। सौजन्य से देखें ।

— रैंडी स्टैनर

3

मुझे समझ में नहीं आता: यह समस्याओं के कारणों का स्पष्टीकरण प्रतीत होता है, लेकिन क्या यहाँ ओपी के प्रश्न का वास्तविक उत्तर है? क्या मेरे ओएस को सेट्यूड शेल स्क्रिप्ट चलाने के लिए कहने का कोई तरीका है?

— टॉम

55

इस समस्या को हल करने का एक तरीका शेल स्क्रिप्ट को एक प्रोग्राम से कॉल करना है जो सेट्यूड बिट का उपयोग कर सकता है।
sudo की तरह कुछ है। उदाहरण के लिए, यहां बताया गया है कि आप इसे C प्रोग्राम में कैसे पूरा करेंगे:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
    setuid( 0 );   // you can set it at run time also
    system( "/home/pubuntu/setuid-test2.sh" );
    return 0;
 }

इसे setuid-test2.c के रूप में सहेजें।
संकलित
करें अब इस कार्यक्रम को द्विआधारी पर सेट करें:

su - nobody   
[enter password]  
chown nobody:nobody a.out  
chmod 4755 a.out

अब, आपको इसे चलाने में सक्षम होना चाहिए, और आप अपनी स्क्रिप्ट को बिना किसी अनुमति के निष्पादित करते हुए देखेंगे।
लेकिन यहां भी आपको या तो स्क्रिप्ट पथ को हार्डकोड करना होगा या इसे कमांड लाइन के रूप में उत्तीर्ण करना होगा।

— हेमंत
स्रोत

25

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

— dsp

39

ध्यान दें कि अगर स्क्रिप्ट का पूरा रास्ता हार्डकोड है, तो भी यह है। शेल पर्यावरण से चर का वारिस होगा, और उनमें से कई हमलावर को मनमाना कोड इंजेक्ट करने की अनुमति देते हैं। PATHऔर LD_LIBRARY_PATHस्पष्ट वैक्टर हैं। कुछ गोले निष्पादित $ENVया $BASHENVया ~/.zshenvपहले भी वे स्क्रिप्ट उचित क्रियान्वित करने लगते हैं, तो आप स्क्रिप्ट के भीतर से इन सब पर से रक्षा नहीं कर सकते हैं। विशेषाधिकारों के साथ शेल स्क्रिप्ट को लागू करने का एकमात्र सुरक्षित तरीका पर्यावरण को साफ करना है । सूडो जानता है कि इसे सुरक्षित तरीके से कैसे करना है। इसलिए अपना खुद का रैपर न लिखें, सुडो का उपयोग करें ।

— ग्लीस

28

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

— माइकल Mrozek

8

@ गिल्स: FYI करें, लिनक्स LD_LIBRARY_PATHदूसरी चीज़ों के बीच अनसेट करता है, जब यह सेट्युड बिट का सामना करता है।

— विशालकाय

3

उपयोग करने के बजाय system, आपको execपरिवार में से किसी एक का उपयोग करने के लिए यह सरल (और अधिक कुशल) लग सकता है - सबसे अधिक संभावना है execve। इस तरह, आप एक नई प्रक्रिया नहीं बनाते हैं या एक शेल शुरू नहीं करते हैं, और आप तर्कों को आगे बढ़ा सकते हैं (यह मानते हुए कि आपका विशेषाधिकार प्राप्त स्क्रिप्ट सुरक्षित रूप से तर्कों को संभाल सकता है)।

— स्पाइट

23

मैं इस तरह से इस नाव में हैं कि कुछ स्क्रिप्ट उपसर्ग:

#!/bin/sh
[ "root" != "$USER" ] && exec sudo $0 "$@"

ध्यान दें कि यह उपयोग नहीं करता है setuidलेकिन बस वर्तमान फ़ाइल के साथ निष्पादित करता है sudo।

— rcrowley
स्रोत

4

यह सेट्युइड का उपयोग नहीं करता है, लेकिन सिर्फ आपको एक sudoसंकेत देता है । (मेरे लिए, सेतु के पूरे बिंदु चीजों को सुडो की आवश्यकता के बिना जड़ के रूप में चलाने की अनुमति दे रहा है।)

— ल्यूक

12

यदि आप कॉल करने से बचना चाहते हैं तो आप sudo some_scriptकर सकते हैं:

  #!/ust/bin/env sh

  sudo /usr/local/scripts/your_script

SETUID कार्यक्रमों को अत्यधिक सावधानी के साथ डिज़ाइन करने की आवश्यकता होती है क्योंकि वे रूट विशेषाधिकारों के साथ चलते हैं और उपयोगकर्ताओं का उन पर बड़ा नियंत्रण होता है। उन्हें हर चीज को पवित्रता-जांचने की जरूरत है। आप इसे स्क्रिप्ट के साथ नहीं कर सकते क्योंकि:

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

कृपया ध्यान दें कि sudoकुछ पवित्रता-जाँच प्रदान करता है, लेकिन यह पर्याप्त नहीं है - अपने स्वयं के कोड में हर पंक्ति की जाँच करें।

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

— मैकीज पाइचोटका
स्रोत

2

मुझे लगता है /ust/bin/envहोना चाहिए /usr/bin/env।

— बॉब

4

आप सूडो + स्क्रिप्ट के नाम के लिए एक उपनाम बना सकते हैं। बेशक, यह सेट करने के लिए और भी अधिक काम है, क्योंकि आपको तब एक उपनाम भी सेट करना होगा, लेकिन यह आपको sudo टाइप करने से बचाता है।

लेकिन अगर आपको भयानक सुरक्षा जोखिमों से कोई आपत्ति नहीं है, तो शेल स्क्रिप्ट के लिए दुभाषिया के रूप में एक सेट्यूइड शेल का उपयोग करें। पता नहीं कि यह आपके लिए काम करेगा, लेकिन मुझे लगता है कि यह हो सकता है।

मुझे बताएं कि मैं वास्तव में ऐसा करने के खिलाफ सलाह देता हूं। मैं सिर्फ शैक्षिक उद्देश्यों के लिए इसका उल्लेख कर रहा हूं ;-)

— wzzrd
स्रोत

5

यह काम करेगा। जैसा कि आपने कहा था। SETUID बिट मालिक के साथ निष्पादन की अनुमति देता है। सेतुइड शेल (जब तक कि यह सेतु के साथ काम करने के लिए डिज़ाइन नहीं किया गया था) किसी भी उपयोगकर्ता के लिए रूट के रूप में चलेगा। यानी कोई भी चला सकता है rm -rf /(और श्रृंखला के अन्य आदेशों से इसे घर पर नहीं चला सकता है )।

— मैकीज पीचोटका

9

@MaciejPiechotka द्वारा यह मत करो घर पर क्या आप काम पर ऐसा करने के लिए स्वतंत्र महसूस करते हैं? :)

— पेट्रफ

4

सुपर [-r reqpath] कमांड [args]

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

सुपर यह बताता है कि उपयोगकर्ता अनुरोधित कमांड को निष्पादित करने की अनुमति देता है या नहीं, यह देखने के लिए एक ``.t.tab '' फ़ाइल। यदि अनुमति दी जाती है, तो सुपर pgm [args] को क्रियान्वित करेगा, जहाँ pgm प्रोग्राम है जो इस कमांड से जुड़ा है। (रूट को डिफ़ॉल्ट रूप से निष्पादन की अनुमति है, लेकिन यदि कोई नियम रूट को बाहर करता है, तो इसे अस्वीकार कर दिया जा सकता है। साधारण उपयोगकर्ताओं को डिफ़ॉल्ट रूप से निष्पादन रोक दिया जाता है।)

यदि कमांड सुपर प्रोग्राम के लिए एक प्रतीकात्मक लिंक (या हार्ड लिंक, भी) है, तो टाइपिंग% कमांड आर्ग्स टाइपिंग के बराबर है% सुपर कमांड आर्ग्स (कमांड सुपर नहीं होना चाहिए, या सुपर यह नहीं पहचानेगा कि यह एक कमांड के माध्यम से आमंत्रित किया जा रहा है। संपर्क।)

http://www.ucolick.org/~will/RUE/super/README

http://manpages.ubuntu.com/manpages/utopic/en/man1/super.1.html

— निज़ाम मोहम्मद
स्रोत

नमस्ते और साइट पर आपका स्वागत है! हम उम्मीद करते हैं कि उत्तर यहां अधिक विस्तृत होंगे। क्या आप अपना उत्तर संपादित कर सकते हैं और बता सकते हैं कि यह कार्यक्रम क्या है और यह ओपी की समस्या को हल करने में कैसे मदद कर सकता है?

— terdon

धन्यवाद निजाम, कुछ घंटों के लिए सुपर जैसे खातों को खोजने की कोशिश करने के लिए फ़ाइल के उपयोगकर्ता के रूप में किसी अन्य उपयोगकर्ता द्वारा निष्पादित होने की अनुमति दी जाती है।

— चाड

2

यदि किसी कारण sudoसे उपलब्ध नहीं है, तो आप C में एक पतली आवरण स्क्रिप्ट लिख सकते हैं:

#include <unistd.h>
int main() {
    setuid(0);
    execle("/bin/bash","bash","/full/path/to/script",(char*) NULL,(char*) NULL);
}

और एक बार जब आप इसे संकलित करते हैं तो इसे उसी के setuidसाथ सेट करें chmod 4511 wrapper_script।

यह एक और पोस्ट किए गए उत्तर के समान है, लेकिन स्क्रिप्ट को स्वच्छ वातावरण के साथ चलाता है और स्पष्ट रूप से /bin/bashइसके द्वारा बुलाए गए शेल के बजाय उपयोग करता है system(), और इसलिए कुछ संभावित सुरक्षा छेद बंद कर देता है।

ध्यान दें कि यह पर्यावरण को पूरी तरह से बाधित करता है। यदि आप कमजोरियों को खोले बिना कुछ पर्यावरण चर का उपयोग करना चाहते हैं, तो आपको वास्तव में उपयोग करने की आवश्यकता है sudo।

जाहिर है, आप यह सुनिश्चित करना चाहते हैं कि स्क्रिप्ट केवल जड़ से ही लेखन योग्य है।

— क्रिस
स्रोत

-3

मैंने पहले यह प्रश्न पाया, सभी उत्तरों से असंबद्ध, यहाँ एक बहुत बेहतर है, जो आपको अपनी बैश स्क्रिप्ट को पूरी तरह से बाधित करने की अनुमति देता है, यदि आप बहुत इच्छुक हैं!

यह आत्म-व्याख्यात्मक होना चाहिए।

#include <string>
#include <unistd.h>

template <typename T, typename U>
T &replace (
          T &str, 
    const U &from, 
    const U &to)
{
    size_t pos;
    size_t offset = 0;
    const size_t increment = to.size();

    while ((pos = str.find(from, offset)) != T::npos)
    {
        str.replace(pos, from.size(), to);
        offset = pos + increment;
    }

    return str;
}

int main(int argc, char* argv[])
{
    // Set UUID to root
    setuid(0);

    std::string script = 
R"(#!/bin/bash
whoami
echo $1
)";

    // Escape single quotes.
    replace(script, std::string("'"), std::string("'\"'\"'"));

    std::string command;
    command = command + "bash -c '" + script + "'"; 

    // Append the command line arguments.
    for (int a = 0; a < argc; ++a)
    {
        command = command + " " + argv[a];
    }

    return system(command.c_str());
}

फिर तुम दौड़ो

g++ embedded.cpp -o embedded
sudo chown root embedded
sudo chmod u+s embedded

— थियोडोर आर स्मिथ
स्रोत

क्यों घटता है ???

— थियोडोर आर। स्मिथ

2

संभवतः क्योंकि यह एक अत्यधिक जटिल समाधान है जो स्ट्रिंग हेरफेर करता है और इसमें शेल कोड होता है। या तो आप एक साधारण लांचर बनाते हैं, या आप सुडो का उपयोग करते हैं। यह सभी विकल्पों में से सबसे खराब है।

— सिराइड