सुरक्षित रूप से sudo के साथ मिल का उपयोग करें

Question

लिनक्स सर्वर पर, मुझे उपयोगकर्ताओं के समूह से रूट विशेषाधिकार हटाने की आवश्यकता है। लेकिन उन उपयोगकर्ताओं के पास वैध कारण हैं जो फ़ाइल नाम, संशोधन तिथियों और अन्य मेटाडेटा के आधार पर फ़ाइलों की खोज करने के लिए "खोज" उपयोगिता का उपयोग करने में सक्षम हैं।

सर्वर पर, फ़ाइल नाम संवेदनशील नहीं हैं, लेकिन फ़ाइल सामग्री हो सकती है।

मैं sudo का उपयोग करना चाहूंगा ताकि उपयोगकर्ता सर्वर पर कहीं भी फाइलों को खोज सकें। "खोज" उपयोगिता महान है, लेकिन यह सभी प्रकार के दुष्प्रभावों के लिए अनुमति देता है, जैसे कि "-exec" का उपयोग मनमाना आदेशों को फैलाने के लिए।

क्या मुझे findअपने प्रतिबंधों के साथ काम करने को मिल सकता है ?

Comments

आमतौर पर आप फ़ाइल नाम पैटर्न के लिए खोज परिणाम नहीं चाहते हैं जिसमें ऐसी फाइलें हों जिन्हें आप वास्तव में एक्सेस नहीं कर सकते हैं। उस संबंध में आपकी आवश्यकता थोड़ी अजीब है।

— HBruijn

कोई आपको प्रश्न में संलग्न करने के लिए मजबूर करता है। मुझे लगता है कि सर्वर फॉल्ट का एक उद्देश्य विषम परिस्थितियों के लिए एक मंच के रूप में सेवा करना है।

— Troels Arvin

सर्वर फाल्ट एक मंच नहीं है, और रिवर्स मनोविज्ञान में प्रयास HBruijn के अवलोकन की वैधता को नहीं बदलते हैं (जो कि, मुझे यकीन है, आपकी मदद करने के प्रयास में लगाया गया है)।

— ऑर्बिट में लाइटनेस दौड़

Answer 1

पता लगाने के बारे में क्या ?

पता लगाता है कि एक या एक से अधिक डेटाबेस अपडेटेड (8) द्वारा तैयार किए गए हैं और मानक आउटपुट, प्रति लाइन कम से कम एक पैटर्न्स से मेल खाने वाले नाम लिखते हैं। यदि --regex निर्दिष्ट नहीं है, तो PATTERNs में ग्लोबिंग वर्ण हो सकते हैं। यदि किसी PATTERN में कोई ग्लोबिंग वर्ण नहीं हैं, तो व्यवहार का पता लगाएं जैसे कि पैटर्न PATTERN थे ।

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

या शायद धीमे भी :

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

यह मैनुअल पेज स्लोकेट के जीएनयू संस्करण का दस्तावेजीकरण करता है। अनधिकृत फ़ाइलों को प्रदर्शित किए बिना पूरे फाइल सिस्टम को खोजने के लिए सिस्टम यूजर्स को स्लो करता है।

Comments

अच्छा विचार। मुझे नहीं पता कि मैंने ऐसा क्यों नहीं सोचा। लेकिन मुझे डर है कि "-d" पैरामीटर को किसी तरह से मनमानी फ़ाइलों में पढ़ने के लिए इस्तेमाल किया जा सकता है, अगर sudo नियम उपयोगकर्ता को "पता" कमांड चलाने की अनुमति देता है?

— ट्रॉल्स अरविन

@ ट्रॉल्सअर्विन: की locateजरूरत नहीं है sudo; केवल इसके updatedbकाम के लिए विशेष विशेषाधिकार की आवश्यकता होती है। इस प्रकार आपके उपयोगकर्ता कभी भी चलने वाले नहीं होने चाहिए या दौड़ने में सक्षम नहीं होने चाहिए sudo locate।

— jwodder

@jwodder: RHEL 7 सर्वर पर: मान लीजिए कि उपयोगकर्ता के पास / डेटा / foo तक पहुंच नहीं है। में / डेटा / फू, वहाँ एक फ़ाइल "somefile.csv" है। अब, जब यू "somefile.csv का पता लगाता है" करता है, तो "डिटेक्ट" से आउटपुट में /data/foo/somefile.csv शामिल नहीं होता है - जब तक कि उपयोगकर्ता sudo के माध्यम से "पता" नहीं लगाते। ("--Nofollow" तर्क का उपयोग करने से मदद नहीं मिलती।)

— ट्रॉल्स अरविन

@ ट्रॉल्सअर्विन लेकिन -dध्वज केवल डेटाबेस पथ सेट करता है? शायद मैंने तुम्हें गलत समझा।

— लेनिए

Answer 2

इसके अनुसार man 7 capabilities

   CAP_DAC_READ_SEARCH
          * Bypass file read permission checks and directory read and execute permission checks;
          * Invoke open_by_handle_at(2).

इसने मेरे लिए काम किया। ('#' से शुरू होने वाली लाइनें रूट हैं, '$' वाले वे रूट हैं) इस मामले में गैर-रूट उपयोगकर्ता wheelसमूह में है।

# cp /usr/bin/find /usr/bin/sudofind
# chmod 710 /usr/bin/sudofind
# chown root:wheel /usr/bin/sudofind
# setcap cap_dac_read_search+ep /usr/bin/sudofind
# exit
$ find /root 
find: ‘/root’: Permission denied
$ sudofind /root
/root /root 
/root/Testbed 
...
... 
$ sudofind /root -exec cat {} \;
cat: /root: Permission denied 
cat: /root/Testbed: Permission denied
$ sudofind /root -printf "%u %g %m %c %p\n"
root root 644 Mon Apr 20 09:20:48.0457518493 2015 /root
root root 755 Fri Dec  4 02:34:03.0016294644 2015 /root/Testbed
...
...
$ # Capability inheritance test..
$ sudofind /root -exec /bin/sleep 10 \; &
[1] 17017
$ getpcaps $(pgrep find)
Capabilities for `17017': = cap_dac_read_search+ep
$ getpcaps $(pgrep sleep)
Capabilities for `17019': =

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

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

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

इसलिए, ध्यान रखें और इसे करने के बारे में सावधान रहें और समझें कि अभी भी इससे जुड़ा जोखिम है, भले ही स्पष्ट चीजें काम न करें।

ओह, और मुझे यह देखने में दिलचस्पी होगी कि क्या किसी के पास अवधारणा हमले का प्रमाण है जो टिप्पणियों में विशेषाधिकार वृद्धि के आधार के रूप में इस तंत्र का उपयोग करता है!

Comments

यह वास्तव में काफी दिलचस्प लग रहा है!

— स्वेन

ऐशे ही? खैर, कोई PoC नहीं है, लेकिन फिर भी दिलचस्प: मंचों .grecurity.net/…

— Lenniey

मुझे यह विचार पसंद है, लेकिन इसकी एक महत्वपूर्ण खामी है: सुडोफिंड अब एक बाइनरी है जो सिस्टम पर किसी भी सॉफ़्टवेयर (जैसे आरपीएम) पैकेज का हिस्सा नहीं है। इसलिए यदि वितरण "खोज" के लिए एक पैच भेजता है, तो सुडोफिंड को अपडेट नहीं किया जाएगा।

— ट्रॉल्स अरविन

@ ट्रॉल्सअर्विन यह जरूरी नहीं कि बुरी चीज हो। यदि आप किसी मौजूदा उपयोगिता के लिए setuid जैसी क्षमताओं को जोड़ रहे हैं जो उन क्षमताओं के लिए डिज़ाइन नहीं किया गया था, तो आप यह सत्यापित करने से पहले अंतर्निहित उपयोगिता के लिए कोई अद्यतन नहीं चाहेंगे कि अद्यतन उपयोगिता को आपके गैर-मानक के साथ सुरक्षित रूप से उपयोग किया जा सके क्षमताओं। इस मामले में कल्पना करें कि यदि कोई अपडेट findकुछ उपयोगकर्ता-आपूर्ति कोड को सीधे निष्पादित करने की क्षमता देता है, awkतो वह क्या कर सकता है।

— एंड्रयू हेनले

सबसे बड़ी समस्या मैं यह देख सकता हूं कि विश्व-लेखन योग्य निर्देशिका जो गैर-खोज योग्य निर्देशिका के नीचे हैं, उन्हें अचानक लिखा जा सकता है।

— तेवियन बार्न्स

Answer 3

मैं उपयोगकर्ताओं को उचित अनुमति दूंगा।

डिफ़ॉल्ट रूप से, यदि umask है 022, तो निर्देशिकाएं बनाई जाती हैं ताकि हर कोई उनमें फ़ाइलों को सूचीबद्ध और स्टेट कर सके। यदि नहीं, तो आप मैन्युअल रूप से निर्देशिका की अनुमति को बिटवाइज़ या उसकी पुरानी अनुमतियों को बदल सकते हैं और 0555:

chmod +0555 foo

और अगर उन उपयोगकर्ताओं को उस निर्देशिका के सभी माता-पिता पर अनुमति निष्पादित नहीं होती है (उदाहरण के लिए, किसी अन्य उपयोगकर्ता की होम निर्देशिका), तो इसका मतलब है कि आपको पहली निर्देशिका कहीं और रखनी चाहिए।

यदि आप केवल कुछ उपयोगकर्ताओं को उस निर्देशिका को पढ़ने और निष्पादित करने देना चाहते हैं, तो आप इसके मोड को बदल सकते हैं 0750, उन उपयोगकर्ताओं को एक समूह में रख सकते हैं , और निर्देशिका के समूह के मालिक को उस समूह में बदल सकते हैं:

groupadd can_read_foo
chmod 0750 foo
chgrp can_read_foo foo
gpasswd -a alice can_read_foo
gpasswd -a bob can_read_foo