CmndAlias का उपयोग करना ALLकभी सुरक्षित नहीं होगा
service network restartबिना किए चलाने के 1000 तरीके हैं sudo service network restart। यहाँ एक शरारती उपयोगकर्ता क्या प्रयास कर सकता है इसका एक उदाहरण है:
$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax
यदि आप उपयोगकर्ताओं को ALLआदेश उपनाम के साथ प्रदान करते हैं , और फिर एक ब्लैकलिस्ट बनाने का प्रयास करते हैं, तो वे हमेशा इसके चारों ओर एक रास्ता खोजने में सक्षम होंगे। ब्लैकलिस्ट बैश, और वे अजगर का उपयोग करेंगे। ब्लैक लिस्ट अजगर, और वे पर्ल का उपयोग करेंगे। ब्लैकलिस्ट पर्ल, और वे PHP का उपयोग करेंगे। कोई नहीं चाहता है कि!
क्या तुम सच में किसी को कुछ करने के लिए नहीं करना चाहते हैं, तो आप थॉमस का कहना है के रूप में करते हैं, और चीजों को वे की एक श्वेत सूची बनाना चाहिए रहे हैं करने की अनुमति दी।
एक अपवाद के साथ एक श्वेतसूची स्थापित करना
बहिष्करण के साथ एक छोटे श्वेतसूची का एक उदाहरण नीचे के पास पाया जा सकता है man sudoers:
pete HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root
The user pete is allowed to change anyone's password except for root on the HPPA
machines. Note that this assumes passwd(1) does not take multiple user names
on the command line.
(वास्तव में मैनपेज का यह उदाहरण असुरक्षित है और रूट के पासवर्ड को बदलने के लिए इसका फायदा उठाया जा सकता है! नीचे दिए गए कमेंट्स देखें कि कैसे)।
हम आपके मामले को अनुकूलित करने का प्रयास कर सकते हैं service, स्टाफ समूह को सभी आदेशों की पेशकश करने के लिए, लेकिन उनservice network कमांडों को बाहर करें जो आपकी चिंता करते हैं:
%staff ALL = /usr/sbin/service *, \
! /usr/sbin/service *network*, \
! /usr/sbin/service *NetworkManager*
( ALLउस स्थिति में Host_Alias को संदर्भित करता है, Cmnd_Alias को नहीं - भ्रमित करना यह नहीं है?)
उपयोगकर्ता को चलाने के लिए सक्षम नहीं होगा sudo bashया sudo teeया sudo wgetया sudo /path/to/malicious_script। यदि आप सावधान हैं तो आप अपने उपयोगकर्ताओं के लिए अधिक व्यवस्थापक आदेश श्वेतसूची में रख सकते हैं। बस विशिष्ट हो!
नोट: मैंने उपरोक्त *शब्द networkसे पहले जोड़ा , बस अगर serviceभविष्य में उपकरण में एक हानिरहित झंडा कभी जोड़ा जाता है । आइए कल्पना करें कि --verboseभविष्य में एक ध्वज जोड़ा गया था, तब उपयोगकर्ता निम्नलिखित चला सकेंगे:
$ sudo service --verbose network restart
इसलिए हमें *सेवा नाम से पहले किसी भी झंडे का उपभोग करने की आवश्यकता है । एक नुकसान यह है कि यह अन्य सेवाओं को अवरुद्ध कर सकता है, जिन्हें आप वास्तव में चलाने वाले उपयोगकर्ताओं को पसंद नहीं करते हैं, उदाहरण के लिए एक सेवा को बुलाया safe-networkया network-monitorअस्वीकार भी किया जाएगा।
उपयोगकर्ताओं को समूह अनुमतियों का उपयोग करके एक फ़ाइल संपादित करने दें
नीचे आप का उपयोग कर विभिन्न प्रयास पा सकते हैं rnanoके माध्यम से sudoएक फ़ाइल या फ़ाइलों बताने के लिए उपयोगकर्ताओं को संपादित। लेकिन वास्तव में वे अधिक जटिल और अधिक खतरनाक हैं जितना उन्हें होना चाहिए।
एक बहुत ही सरल और सुरक्षित समाधान उन विशिष्ट फ़ाइलों पर समूह अनुमतियों को बदलना है जिनके लिए आप संपादन अधिकार खोलना चाहते हैं। यहां कुछ उदाहरण दिए गए हैं:
### Give steve the ability to edit his nginx config:
$ chgrp steve /etc/nginx/sites-available/steves_dodgy_project
$ chmod g+rw /etc/nginx/sites-available/steves_dodgy_project
### Let all members of the staff group edit the group_website config:
$ chgrp staff /etc/nginx/sites-available/group_website
$ chmod g+rw /etc/nginx/sites-available/group_website
यदि आपको अधिक महीन दाने वाले नियंत्रण की आवश्यकता होती है (उदाहरण के लिए: सिर्फ 3 उपयोगकर्ताओं के लिए, लेकिन सभी कर्मचारी सदस्यों तक नहीं) तो आप addgroupकमांड का उपयोग करके एक नया समूह बना सकते हैं , और इसमें कुछ ही उपयोगकर्ताओं को जोड़ सकते हैं।
उपयोगकर्ताओं को किसी फ़ाइल को संपादित करने दें sudo
इस उत्तर के शेष भाग की जांच हो गई कि sudoआपके उपयोगकर्ताओं को लचीलापन प्रदान करने का प्रयास करते समय आपके कॉन्फ़िगरेशन में छेद छोड़ना कितना आसान है । मैं निम्नलिखित में से कोई भी करने की सलाह नहीं दूंगा!
यदि आप किसी विशिष्ट फ़ाइल को संपादित करने के लिए अपने उपयोगकर्ताओं को एक्सेस देना चाहते हैं, तो आप उपयोग करने का प्रयास कर सकते हैं rnano:
%staff ALL = /bin/rnano /etc/nginx/sites-available/host
rnanoकेवल उन्हें निर्दिष्ट फ़ाइल को संपादित करने देगा। एक दुर्भावनापूर्ण उपयोगकर्ता को एक अलग अपस्टार्ट सेवा (उदाहरण के लिए /etc/init.d/urandom) को संपादित करने से रोकने के लिए , और उस पर एक पंक्ति जोड़ना महत्वपूर्ण है जो चलेगा service network restart।
दुर्भाग्य से मुझे rvimपर्याप्त रूप से प्रतिबंधित करने का कोई तरीका नहीं मिला (उपयोगकर्ता अभी भी किसी भी फ़ाइल का उपयोग करके खोल सकता है :e), इसलिए हम इसके साथ फंस गए हैं nano।
दुर्भाग्य से उपयोगकर्ताओं को कई फ़ाइलों को संपादित करने की अनुमति देना बहुत कठिन है ...
उपयोगकर्ताओं को कई फ़ाइलों को संपादित करने दें (जिस तरह से इसे और अधिक कठिन होना चाहिए)
1. असुरक्षित दृष्टिकोण
वाइल्डकार्ड से सावधान रहें! यदि आप बहुत अधिक लचीलापन (या किसी भी लचीलेपन) की पेशकश करते हैं, तो इसका फायदा उठाया जा सकता है:
%staff ALL = /bin/rnano /etc/nginx/sites-available/* # UNSAFE!
इस स्थिति में, एक दुर्भावनापूर्ण उपयोगकर्ता किसी अन्य अपस्टार्ट सेवा स्क्रिप्ट को संपादित करने में सक्षम होगा, और फिर उसे चलाएगा:
$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system
(सूडो वास्तव में आदेश पर रोकथाम .और ..विस्तार करते हैं, लेकिन दुर्भाग्य से तर्कों पर नहीं।)
मैं उम्मीद कर रहा था कि ऐसा कुछ हो सकता है, लेकिन यह अभी भी असुरक्षित है:
%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]* # UNSAFE!
चूंकि sudoवर्तमान में केवल ग्लोब पैटर्न प्रदान करता है , जो कि *किसी भी चीज़ से मेल खाएगा - यह एक regexp नहीं है!
(संपादित करें: मैंने विचार किया कि क्या आप अपनी स्थिति में उपरोक्त के साथ दूर हो सकते हैं, क्योंकि नीचे कोई उप-फ़ोल्डर नहीं हैं sites-available। हमने मांग की थी कि फ़ोल्डर के बाद एक चार मिलान किया जाए, और /..एक फ़ाइल नाम के बाद विफल होना चाहिए। हालांकि यह एक नहीं है। व्यावहारिक समाधान, क्योंकि rnanoकई तर्कों को स्वीकार करता है। और वैसे भी सामान्य रूप से यह अभी भी एक फ़ोल्डर पर असुरक्षित होगा जिसमें सबफ़ोल्डर थे!)
यहां तक कि अगर हमारे पास कोई सबफ़ोल्डर नहीं है, और हम किसी भी लाइन को शामिल नहीं करते हैं /../, तो एक *ग्लोब की पेशकश करने वाले नियम का अभी भी शोषण किया जा सकता है, क्योंकि rnanoकई तर्क (उन पर साइकिल चलाना) स्वीकार करते हैं <C-X>, और अंतरिक्ष को *ग्लोब द्वारा खुशी से स्वीकार किया जाता है ।
$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system
2. लिफाफा धक्का (भी असुरक्षित)
तो क्या होगा यदि हम रिक्त स्थान वाली किसी भी रेखा को अस्वीकार कर दें, या पहुँचने का प्रयास करें /..? तब एक अंतिम व्यावहारिक समाधान यह हो सकता है:
# I tried hard to make this safe, but in the end I failed again.
# Please don't use this unless you are really smart or really stupid.
%staff ALL = /bin/rnano /etc/nginx/sites-available/*, \
! /bin/rnano */..*, \
! /bin/rnano /etc/nginx/sites-available/, \
! /bin/rnano */., \
! /bin/rnano * *
# CONCLUSION: It is still NOT SAFE if there are any subfolders, due to
# the bug in rnano described below.
हम "के तहत" फ़ोल्डर कुछ भी स्वीकार लेकिन हम भी करने के लिए कोई कॉल को अस्वीकार rnanoकरता है, तो /..या /.या /.बहिष्करण /..बहिष्करण को निरर्थक बनाता है , लेकिन मैंने स्पष्टता के लिए दोनों को छोड़ दिया है।)
मुझे फ़ोल्डर मिला और /.बहिष्करण की आवश्यकता थी क्योंकि अन्यथा उपयोगकर्ता फ़ोल्डर को ही लक्षित कर सकता है। अब आप सोच सकते हैं कि rnanoयदि एक फ़ोल्डर में बताया गया है, लेकिन आप गलत होंगे। वास्तव में मेरा संस्करण (2.2.6-1ubuntu1) एक हल्की चेतावनी और एक खाली फ़ाइल के साथ शुरू होता है, फिर <C-X>मुझे किसी भी फ़ाइलनाम को इनपुट करने के लिए कहता है जिसे मैं सहेजना चाहता हूं , एक नया हमला वेक्टर खोलना! अच्छी तरह से कम से कम यह एक मौजूदा फ़ाइल (मैंने किया एक परीक्षण में) को अधिलेखित करने से इनकार कर दिया। वैसे भी, चूंकि सूडो के साथ सबफ़ोल्डर्स को ब्लैकलिस्ट करने का कोई तरीका नहीं है, इसलिए हमें यह निष्कर्ष निकालना चाहिए कि यह दृष्टिकोण फिर से असुरक्षित है। क्षमा करें उपयोगकर्ता!
इस खोज ने मुझे nano'' प्रतिबंधित '' मोड की गहनता पर संदेह किया । वे कहते हैं कि एक श्रृंखला केवल सबसे कमजोर कड़ी के रूप में मजबूत है। मुझे sudoब्लैकलिस्ट-ब्लैक-मैजिक का संयोजन महसूस होने लगा है और rnanoयह डेज़ी की श्रृंखला से अधिक सुरक्षित नहीं हो सकता है।
3. सुरक्षित लेकिन सीमित दृष्टिकोण
ग्लब्स बहुत प्रतिबंधित हैं - वे हमें कई बार एक चरित्र वर्ग से मेल नहीं खाते। आप कई फ़ाइल संपादन पेश कर सकते हैं, यदि आपके सभी फ़ाइलनामों की लंबाई समान है (इस मामले में hostएक अंक के बाद):
%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9] # SAFE
लेकिन यदि आप उपयोगकर्ता को विभिन्न फ़ाइलों को संपादित करने के लिए पहुँच देना चाहते हैं, तो आपको प्रत्येक फ़ाइल को स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता हो सकती है:
%staff ALL = /bin/rnano /etc/nginx/sites-available/hothost \
/bin/rnano /etc/nginx/sites-available/coldhost \ # SAFE
/bin/rnano /etc/nginx/sites-available/wethost \
/bin/rnano /etc/nginx/sites-available/steves_dodgy_project
*किसी भी बिंदु परउपयोग करने के लिए परीक्षा न करें । ऊपर के खंड 1. और 2. क्यों देखें! याद रखें: एक छोटी सी पर्ची पूरे सुपरसुअर खाते, और पूरे सिस्टम से समझौता कर सकती है।
4. अपने तर्क परीक्षक को लिखें (सुरक्षा अब आपकी जिम्मेदारी है)
मुझे आशा है कि वे sudoभविष्य में regexp समर्थन जोड़ देंगे ; अगर इसे सही तरीके से इस्तेमाल किया जाए तो यह बहुत सारी समस्याओं को हल कर सकता है। लेकिन हमें तर्कों के गुणों की जांच करने की क्षमता की आवश्यकता हो सकती है (केवल फ़ाइलों, केवल फ़ोल्डर्स या केवल कुछ झंडे की अनुमति देने के लिए)।
लेकिन सुडो में लचीलापन बनाने के लिए एक विकल्प है। उत्तरदायित्व मढ़ना:
%staff ALL = /root/bin/staffedit *
फिर staffeditयह जांचने के लिए कि उपयोगकर्ता द्वारा पारित किए गए तर्क कानूनी हैं या नहीं, यह जांचने के लिए अपनी खुद की स्क्रिप्ट या निष्पादन योग्य लिखें ।
networkingऔर हैnetwork-manager? इसके अलावा, आपके उपयोगकर्ताओं कीsudoपहुंच क्यों है ? उन्हें तब तक नहीं करना चाहिए जब तक कि आप उन्हें पूरे रूट विशेषाधिकार न दें।