लिनक्स उपयोगकर्ता को उन फाइलों पर प्रतिबंधित करें, जिनके पास वह है

24

एक साझा वेबहोस्टिंग कंपनी के सर्वर सेटअप की कल्पना करें जहां कई (~ 100) ग्राहकों के पास एकल सर्वर तक पहुंच है।

बहुत सारे वेब "सॉफ़्टवेयर" 0777 फ़ाइलों को चोदने की सलाह देते हैं । मैं इन ट्यूटोरियल्स के बाद हमारे ग्राहकों के बारे में घबरा रहा हूं, अपने फाइल हमारे अन्य ग्राहकों के लिए खोल रहा हूं। (मैं निश्चित रूप से cmod 0777खुद को अनावश्यक रूप से उपयोग नहीं कर रहा हूं!) क्या यह सुनिश्चित करने की कोई विधि है कि ग्राहक केवल अपनी खुद की फाइलों तक पहुंच सकते हैं और उन्हें अन्य उपयोगकर्ताओं से विश्व पठनीय फ़ाइलों तक पहुंचने से रोक सकते हैं?

मैंने AppArmor में देखा , लेकिन यह बहुत कसकर एक प्रक्रिया के लिए युग्मित है, जो उस वातावरण में विफल हो रहा है।

— फिलिप
स्रोत

12

मैं वास्तव में इस बात पर विचार करूंगा कि क्या "वेब सॉफ्टवेयर" की सिफारिशें chmod files 0777कड़ाई से आवश्यक हैं, अर्थात समस्या के मूल कारण को संबोधित करें, बजाय इसके कि लक्षण के, ऐसा करने से, कोई भी किसी और की फ़ाइलों को पढ़ सकता है। कई बार सभी एक्सेस सिफारिश को समर्थन कॉल से बचने का एक सस्ता तरीका है, या अनुमति को सही ढंग से सेट करने में सक्षम होने में तकनीकी कौशल की कमी है। लगभग किसी भी मामले में 0777अनुरोध किए जाने पर मुझे फ़ाइलों को सेट करना या एप्लिकेशन को पूर्ण रूट एक्सेस प्रदान करना पड़ता है । उपयोगकर्ताओं और / या विक्रेताओं की शिक्षा यहाँ बड़े पैमाने पर मदद करती है।

— कॉस्मिक ओस्सिफ्रेज

3

@CosmicOssifrage, उपयोगकर्ताओं को आसानी से शिक्षित नहीं किया जा सकता है, वे निर्देश या मैनुअल पढ़ना नहीं चाहते हैं।

— क्रिस्टियन सियुपिटु

12

कोई भी "वेब सॉफ़्टवेयर" जो अभी भी 777 अनुमतियों की सिफारिश करता है, उसे बाहर निकालने और शॉट करने की आवश्यकता है । उपयोग suexecया mpm_itkसमान।

— शादुर

3

@CosmicOssifrage मुझे नहीं लगता कि फिलिप chmod 0777अपनी फ़ाइलों के लिए उपयोगकर्ताओं को बता रहा है या मजबूर कर रहा है । मुझे लगता है कि वह उनके बारे में घबरा रहा है loltoturialz.com/php_problemsऔर chmod 0777खराब तरीके से लिखे गए लेख का आंख मूंदकर अनुसरण कर रहा है। वास्तव में उन्हें ऐसा करने से रोकने के लिए, या किसी को अपना सामान चोरी करने से परेशान होने से रोकने का कोई तरीका नहीं है।

— केविन -

2

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

— Dani_l

34

बाहरी दुनिया और संरक्षित फ़ाइलों के बीच एक प्रतिबंधित और अपरिवर्तनीय निर्देशिका रखें , जैसे

/
 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

या /home/joe/restricted/public_html।

प्रतिबंधित का मतलब है कि केवल उपयोगकर्ता और शायद वेब सर्वर इसे पढ़ सकते हैं (जैसे मोड 0700/ 0750या कुछ एसीएल )।

अपरिवर्तनीयता chattr +iको स्वामित्व को बदलने या इसके साथ कुछ करने के लिए किया जा सकता है root:joe।

उबंटू पर उस पदानुक्रम को बनाने का एक आसान तरीका संपादित करना /etc/adduser.confऔर सेट GROUPHOMESकरना होगा yes।

— क्रिस्टियन सियुपिटु
स्रोत

15

एक विकल्प है, जिस पर आप विचार कर सकते हैं (इसके लिए आप कितना काम करना चाहते हैं)।

जैसा कि अन्य लोग पहले से ही पोस्ट कर चुके हैं, "सामान्य रूप से" आप किसी को शेल-एक्सेस के साथ दुनिया-पढ़ने योग्य फ़ाइलों को पढ़ने से नहीं रोक सकते।

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

जब मैं एक उपयोगकर्ता के पास वेबफाइल्स का उपयोग करने के लिए था, तो मैंने एक सहज दृष्टिकोण किया, लेकिन मैं उसे वेबफ़ोन के बाहर अन्य फ़ाइलों को देखने के लिए नहीं करना चाहता था।

इसमें बहुत अधिक ओवरहेड था, सेटअप करने के लिए एक गड़बड़ थी, और हर बार जब मैंने कुछ अपडेट किया, तो यह टूट गया।

लेकिन आज के लिए मुझे लगता है कि आप ओपनएसएसएच चेरोट विकल्प के साथ इसे बहुत आसान हासिल कर सकते हैं :

विकीबुक ओपनएसएसएच

— डेनिस नोल्टे
स्रोत

SFTP के लिए चुरोट को लागू करना आसान है, लेकिन मुझे यकीन नहीं है कि यह शेल एक्सेस के लिए इतना आसान है। आपको प्रत्येक उपयोगकर्ता के लिए सभी बायनेरिज़ और लाइब्रेरीज़ के साथ एक क्रोकेट सेटअप करना होगा।

— क्रिस्टियान सियुपिटु

2

यह विशिष्ट कार्यान्वयन है। ARCHLINUX में एक विशिष्ट आर्क-चेरोट कमांड है जो सभी अतिरिक्त बाँध माउंट आदि की देखभाल करता है। wiki.archlinux.org/index.php/Change_Root#Change_root

— Dani_n

@CristianCiupitu ने जो कुछ किया, वह सभी विशिष्ट उप-पुस्तकालयों को जोड़ने के साथ केवल एक विशिष्ट उपसमूह की अनुमति देता है, इसलिए मैंने कहा कि यह गड़बड़ है :) Dani_l सच है, मेरा सेटअप एक डेबियन सर्वर था, मुझे गेंटू में जाँच करने का समय कभी नहीं मिला ।

— डेनिस नोल्टे

@ डैनी_एल: स्थापित पैकेजों के बारे में क्या? arch-chrootआदेश है कि कवर करने के लिए प्रतीत नहीं होता। और फिर सभी डुप्लिकेट के साथ व्यर्थ डिस्क स्थान का मुद्दा भी है। मैं यह नहीं कह रहा कि यह करना असंभव है, बस यह वर्तमान में थोड़ा अधिक जटिल हो सकता है।

— क्रिस्टियन सियुपिटु

1

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

— वैध

11

मैंने पाया है कि POSIX एक्सेस कंट्रोल लिस्ट को आप, सिस्टम एडमिनिस्ट्रेटर के रूप में, अपने यूजर्स को अपनी खुद की अज्ञानता से बचाने के लिए, रेगुलर यूजर-ग्रुप-अन्य फाइल सिस्टम की अनुमति को ओवरराइड करके, बिना ज्यादा मौका दिए मौका दे सकते हैं। ।

वे विशेष रूप से उपयोगी हो सकते हैं यदि आप उदाहरण के लिए (फाई) घर निर्देशिकाओं को विश्व सुलभ होने की आवश्यकता है क्योंकि वेबकंट को अपाचे के लिए सुलभ होने की आवश्यकता है ~/public_html/। (हालांकि एसीएल के साथ आप अब रिवर्स कर सकते हैं, सभी के लिए पहुंच हटा दें और अपाचे उपयोगकर्ता के लिए एक विशिष्ट प्रभावी एसीएल का उपयोग करें।)

हां, एक जानकार उपयोगकर्ता उन्हें फिर से हटा / ओवरराइड कर सकता है, बस असामान्य रूप से पर्याप्त है जो कि संभावना नहीं है, और वे उपयोगकर्ता जो आमतौर पर chmod -R 777 ~/वैसे भी सुविधाजनक नहीं हैं, ठीक है?

आपको aclमाउंट विकल्प के साथ फाइल सिस्टम को माउंट करने की आवश्यकता है :

 mount -o remount,acl /home

कई वितरणों में डिफ़ॉल्ट उपयोगकर्ता समूह बनाने के लिए होता है, प्रत्येक उपयोगकर्ता का अपना प्राथमिक समूह होता है, और मैंने सभी उपयोगकर्ताओं को द्वितीयक समूह में अकल्पनीय नाम के साथ सेट किया है users।

ACL का उपयोग करना अब अन्य उपयोगकर्ताओं को घरेलू निर्देशिकाओं तक पहुँचने से रोकने के लिए तुच्छ है:

पहले:

 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

अब समूह के सदस्यों के लिए प्रभावी निर्देशिका अनुमतियों usersको 0बिना पढ़े, लिखे या उपयोग किए बिना सेट करें:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

+संकेत वहाँ एसीएल सेटिंग्स की उपस्थिति को दर्शाता है। और getfaclपुष्टि कर सकते हैं कि:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1
user::rwx
group::rwx
group:users:---
mask::rwx
other::rwx

group:users:---बताते हैं कि समूह को प्रभावी ढंग से पहुँच नहीं सही होने, अन्य किया जा रहा है के लिए नियमित रूप से अनुमतियों के बावजूदother::rwx

और user1 के रूप में परीक्षण:

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

साझा सिस्टम पर एक दूसरा आम समाधान है ऑटोमोटिव माउंट होम डाइरेक्टरीज़ ऑन डिमांड एक सर्वर जो शेल एक्सेस के लिए समर्पित है। यह मूर्खतापूर्ण प्रमाण से दूर है, लेकिन आम तौर पर केवल मुट्ठी भर उपयोगकर्ताओं को ही समवर्ती रूप से लॉग इन किया जाएगा, केवल उन उपयोगकर्ताओं की होम निर्देशिका दिखाई और पहुंच योग्य है।

— HBruijn
स्रोत

5

"फाई" क्या है ? जब तक वे "उदा", "अर्थात", "आदि" और शायद ओपी जैसे क्लासिक एक नहीं हैं, तब तक मैं समसामयिक या संक्षिप्त रूप का उपयोग करने की सलाह नहीं दूंगा।

— क्रिश्चियन सियुपिटु

3

लिनक्स कंटेनर (LXC) चेरोट और अलग प्रणाली का सबसे अच्छा संयोजन हो सकता है।

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

LXC के लेखक स्टीफन ग्रेबर के पास आपके शुरू करने में मदद करने के लिए एक अच्छा ट्यूटोरियल है।

— maniaque
स्रोत

आप वास्तव में विभिन्न ऑपरेटिंग सिस्टम को संयोजित नहीं कर सकते हैं, क्योंकि उन सभी को लिनक्स कर्नेल का उपयोग करने की आवश्यकता है , लेकिन आप विभिन्न वितरणों का उपयोग कर सकते हैं ।

— क्रिश्चियन सियुपिटु

1

धन्यवाद :) हाँ, विभिन्न लिनक्स कर्नेल आधारित ऑपरेटिंग सिस्टम।

— जूल

@CristianCiupitu क्या आपका मतलब समान लिनक्स लिनक्स कर्नेल से है? या क्या आपका मतलब है कि प्रत्येक कंटेनर में कर्नेल का एक अलग संस्करण हो सकता है?

— मेघों ने

@agksmehx, सभी LXC कंटेनर होस्ट के कर्नेल को साझा करते हैं । केवल उनके अनुप्रयोगों और पुस्तकालयों का उपयोग किया जाता है। उदाहरण के लिए यदि आपके पास उबंटू 14.04 कंटेनर के साथ RHEL 7 होस्ट है, तो RHEL कर्नेल (3.10.0-123) का उपयोग किया जाएगा, जबकि Ubuntu एक (3.13.0-24.46) का उपयोग नहीं किया जाएगा; इस टिप्पणी को भी ट्यूटोरियल से पढ़ें । वैसे, चूंकि कंटेनरों की गुठली का उपयोग नहीं किया जाता है, इसलिए कुछ डिस्क स्थान को बचाने के लिए उन्हें निकालना एक अच्छा विचार हो सकता है।

— क्रिस्टियन सियुपिटु

@CristianCiupitu यही मैंने सोचा है। यह उत्तर या टिप्पणी से स्पष्ट नहीं था, इसलिए मैं स्पष्ट करना चाहता था।

— एग्क्स mehx

3

उदाहरण के लिए, यदि आप चाहते हैं कि उपयोगकर्ता को केवल उसकी अपनी homeनिर्देशिका तक पहुँच हो , तो आपको यह करना चाहिए:

cd /home
sudo chmod 700 *

अब /home/usernameकेवल इसके मालिक को दिखाई दे रहा है। इस सभी नए उपयोगकर्ताओं, संपादन के लिए डिफ़ॉल्ट बनाने के लिए /etc/adduser.confऔर सेट DIR_MODEकरने के लिए 0700करने के बजाय 0755डिफ़ॉल्ट।

यदि आप डिफ़ॉल्ट DIR_MODE को बदलना चाहते हैं, तो यह आपके वितरण पर निर्भर करता है, जिस पर मैंने पोस्ट किया है Ubuntu।

संपादित करें

जैसा कि @Dani_l ने सही उल्लेख किया है, यह उत्तर उन्हें पढ़ने योग्य नहीं बनाने के लिए सही है।

— मारेक
स्रोत

वे एक कारण के लिए "दुनिया को पठनीय" कहते हैं।

— मार्क के कोवन

1

@DennisNolte वास्तव में, यह मदद करता है, भले ही फाइलें विश्व पठनीय हों, अगर वे एक निर्देशिका में हैं जो आपने न तो पढ़ा है और न ही आप पर निष्पादित किया है, वैसे भी उन्हें नहीं पढ़ सकते हैं।

— वैध

1

@ सच, मेरी टिप्पणी को हटा देना क्योंकि यह स्पष्ट रूप से गलत है।

— डेनिस नोल्टे

2

सिर्फ पांडित्य होना - नहीं, वहाँ नहीं है।
@ मारेक ने एक सही उत्तर दिया , लेकिन आपका प्रश्न गलत है - आप किसी को भी "दुनिया में पढ़ने योग्य" फाइलों तक पहुंचने से नहीं रोक सकते।
या तो वे दुनिया में पढ़ने योग्य हैं, या वे नहीं हैं। @ मारेक का उत्तर उन्हें पढ़ने योग्य नहीं बनाने के लिए सही है।

— Dani_l
स्रोत

2

गलत, चेरोट / जेल उपयोगकर्ता को एक सबफ़ोल्डर में ले जाता है और "सामान्य रूप से" विश्व-पठनीय फ़ाइलों को पढ़ने में असमर्थ होता है।

— डेनिस नोल्टे

1

-1 मुझे लगता है कि आप ओपी के प्रश्न की अनावश्यक रूप से आलोचना कर रहे हैं। वह अपने ग्राहकों को उनकी अनुमति के बारे में स्मार्ट नहीं होने की स्थिति में सुरक्षा जाल देना चाहता है। लेकिन मुझे ऐसा नहीं लगता है कि ओपी को इस बात की जानकारी नहीं है कि यूनिक्स की फाइल कैसे काम करती है या बेसिक सिक्योरिटी प्रिंसिपल।

— केविन - मोनिका

इसके अलावा, आप फ़ाइलों को एक 000 अनुमतियों की निर्देशिका के अंदर एक निर्देशिका में रख सकते हैं, फिर कोई भी उन तक पहुंच नहीं सकता है, भले ही फाइलें विश्व में पढ़ने योग्य हों।

— वैध

कोई भी नहीं? जड़ भी नहीं? ;-)

— दानी_ल

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

— डेनिस नोल्टे

0

मुझे अब तक दिए गए जवाबों में 'प्रतिबंधित खोल' का कोई जिक्र नहीं दिखता।

ln / bin / bash / bin / rbash

इसे उनके लॉगिन शेल के रूप में सेट करें।

— bbaassssiiee
स्रोत

0

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

आप चाहते हैं कि कुछ फाइलें उपयोगकर्ता के साथ-साथ वेब सर्वर के लिए भी सुलभ हों, लेकिन अन्य उपयोगकर्ताओं के लिए नहीं। लेकिन जैसे ही वेब सर्वर उन्हें एक्सेस कर सकता है, कोई अन्य उपयोगकर्ता उन्हें अपनी वेब साइट के अंदर फ़ाइल के लिए सिमलिंक लगाकर पढ़ सकता है।

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

इन दो उपयोगकर्ताओं वाला एक समूह बनाएं। अब उस समूह और उपयोगकर्ता रूट के साथ एक निर्देशिका बनाएं। उस निर्देशिका की अनुमति होनी चाहिए 750, जिसका अर्थ है कि रूट की पूर्ण पहुंच है और समूह ने पहुंच को पढ़ा और निष्पादित किया है। उस निर्देशिका के अंदर आप प्रत्येक दो उपयोगकर्ताओं के लिए होम निर्देशिका बना सकते हैं। इसका अर्थ है कि उपयोगकर्ता की होम डायरेक्टरी में अब फॉर्म नहीं होगा /home/username, बल्कि कम से कम एक और निर्देशिका घटक के साथ कुछ होगा। यह कोई समस्या नहीं है, कुछ भी नहीं है कि घर निर्देशिकाओं को उस विशिष्ट सम्मेलन के अनुसार नामित करने की आवश्यकता है।

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

— kasperd
स्रोत