services unprivileged user ने कशा चालवायच्या

सर्व गोष्टी root म्हणून का चालवू नयेत

Root मशीनवर काहीही करू शकते: प्रत्येक फाईल वाचणे, कोणतेही सेटिंग बदलणे किंवा संपूर्ण सिस्टम डिलीट करणे. जेव्हा तुम्ही एखादी service root म्हणून चालवता, तेव्हा तुम्ही त्या service ला सर्व अधिकार देता. जर त्या service मध्ये एखादी bug असेल ज्याचा फायदा attacker घेऊ शकतो, तर त्यांना फक्त ती service मिळत नाही, तर त्यांना root एक्सेस मिळतो आणि root म्हणजे संपूर्ण server आहे. Unprivileged user म्हणून चालवल्यामुळे हानी मर्यादित राहते. मर्यादित account वर चालणाऱ्या service मधील bug मुळे attacker ला फक्त तेवढेच अधिकार मिळतात जे त्या account ला उपलब्ध आहेत, जे सहसा नगण्य असतात.

यालाच 'principle of least privilege' म्हणतात: सिस्टमच्या प्रत्येक भागाला त्याचे काम करण्यासाठी नेमके आवश्यक असलेले अधिकार द्या, त्यापेक्षा जास्त नाही. एखाद्या compromise मुळे होणाऱ्या नुकसानीची व्याप्ती (blast radius) मर्यादित करण्यासाठी ही सर्वात प्रभावी पद्धत आहे, आणि आधुनिक server वर ही पद्धत वापरणे अत्यंत सोपे आहे.

प्रत्येक service साठी एक समर्पित account

पारंपारिक पद्धत म्हणजे प्रत्येक service साठी एक वेगळा system user तयार करणे, ज्याचा मालकी हक्क फक्त त्या service च्या फाईल्सवर असेल आणि तो log in करू शकणार नाही. web app साठी system account असे असू शकते:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

येथे प्रत्येक flag महत्त्वाचा आहे. --system मुळे ते एक service account बनते, मानवी login नाही. --no-create-home मुळे आवश्यक नसलेले home directory वगळले जाते. --shell /usr/sbin/nologin चा अर्थ असा आहे की जर एखाद्या attacker ने कशाही प्रकारे त्या account चा ताबा मिळवला, तरी तो त्याद्वारे shell उघडू शकणार नाही. हे account फक्त एक process आणि त्याच्या फाईल्सची मालकी राखण्यासाठी अस्तित्वात असते.

त्यानंतर त्या user ला फक्त आवश्यक असलेल्या फाईल्स द्या, त्यापेक्षा जास्त नाही:

sudo chown -R appsvc:appsvc /opt/myapp

आता ती service स्वतःची directory वाचू आणि लिहू शकते आणि डिस्कवर इतर कुठेही तिचा संबंध नसेल. जर ती कधी exploit झाली, तर attacker बदलू शकणाऱ्या फाईल्स /opt/myapp पर्यंत मर्यादित असतील; ते account जगाला उपलब्ध असलेल्या (world-readable) गोष्टी वाचू शकते, पण ते सिस्टममधील इतर गोष्टी बदलू शकत नाही.

systemd ला ते user म्हणून चालवण्यास सांगा

एकदा account तयार झाले की, systemd ला ती service त्या user म्हणून चालवण्यास सांगा. unit file मध्ये, एक ओळ हे काम करते:

[Service]
ExecStart=/opt/myapp/bin/server
User=appsvc
Group=appsvc

User=appsvc मुळे process root ऐवजी त्या account च्या मर्यादित privileges सह सुरू होतो. systemd अंतर्गत application चालवण्याची ही एक सामान्य आणि प्रमाणित पद्धत आहे, आणि तुम्ही लिहिलेल्या प्रत्येक service साठी ही पद्धत वापरणे फायदेशीर ठरते.

किंवा DynamicUser वापरून account पूर्णपणे वगळा

systemd एक पाऊल पुढे जाऊ शकते आणि तुमच्यासाठी एक 'throwaway' user तयार करू शकते, जो फक्त service चालू असेपर्यंतच अस्तित्वात असतो. DynamicUser=yes सेट करा आणि तुम्हाला कोणत्याही account चे व्यवस्थापन करण्याची गरज नाही:

[Service]
ExecStart=/opt/myapp/bin/server
DynamicUser=yes
StateDirectory=myapp

सुरुवातीला, systemd एक unused user ID नियुक्त करते; थांबताना, ते मुक्त करते. service ला एक खाजगी /tmp देखील मिळते, जी filesystem चा बहुतेक भाग read-only स्वरूपात पाहू शकते, आणि /var/lib/myapp अंतर्गत एक writable state directory मिळते जी StateDirectory= द्वारे सेट केली जाते आणि प्रदान केली जाते. ज्या self-contained service ला फक्त स्वतःच्या state directory ची गरज असते, त्यांच्यासाठी DynamicUser=yes ही मजबूत isolation मिळवण्याची सर्वात सोपी पद्धत आहे, कारण attacker साठी लक्ष्य करण्यासाठी कोणतेही long-lived account नसतेच.

Units हाताने लिहिणे कठीण आहे, आणि hardening directives योग्यरित्या सेट करणे हेच सर्वात महत्त्वाचे आहे. the systemd service and timer guide मधील generator तुमच्यासाठी या options भरू शकतो जेणेकरून unit पहिल्याच प्रयत्नात योग्य असेल.

हे इतर गोष्टींशी कसे संबंधित आहे

Least privilege हा एक स्तर आहे, आणि तो इतर गोष्टींची जागा घेण्याऐवजी त्यांच्यासोबत काम करतो. default-deny firewall कोणती service एक्सेस करू शकते यावर नियंत्रण ठेवते; unprivileged user म्हणून चालवणे हे service breach झाल्यास ती काय करू शकते यावर नियंत्रण ठेवते; आणि hardened SSH सुरुवातीलाच attackers ला मशीनपासून दूर ठेवते. यांपैकी एकही गोष्ट पुरेशी नाही, आणि एकत्रितपणे याचा अर्थ असा आहे की एका service मधील bug मुळे संपूर्ण server compromise होत नाही.

पुढे जाण्यापूर्वी, संपूर्ण मशीनसाठी hardening checklist तपासा आणि काम करण्यासाठी त्याची एक वैयक्तिक प्रत तयार करा:

FAQ

मी service root म्हणून का चालवू नये?

कारण root मशीनवर काहीही करू शकते, त्यामुळे root म्हणून चालवलेली आणि exploit झालेली service attacker ला केवळ ती service नाही, तर संपूर्ण server देते. service ला मर्यादित, unprivileged account म्हणून चालवल्यामुळे हानी त्या account च्या एक्सेस मर्यादेपर्यंतच राहते. root चा वापर फक्त administration साठी करा आणि प्रत्येक long-running service प्रतिबंधित user म्हणून चालवा.

मी log in करू न शकणारा user कसा तयार करू?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME चालवा. nologin shell चा अर्थ असा आहे की जर credentials चोरीला गेले तरी ते account interactive session उघडू शकत नाही, --system त्याला service account म्हणून चिन्हांकित करते, आणि --no-create-home आवश्यक नसलेले home directory वगळते. chown वापरून त्याला फक्त त्याच्या स्वतःच्या फाईल्सची मालकी द्या.

systemd DynamicUser काय आहे?

DynamicUser=yes systemd ला service साठी एक तात्पुरता user तयार करण्यास सांगते जो फक्त ती चालू असेपर्यंतच अस्तित्वात असतो, त्यामुळे तुम्हाला कधीही long-lived account व्यवस्थापित करण्याची गरज पडत नाही. ते service ला एक खाजगी /tmp देखील देते, जो बहुतेक read-only filesystem view आहे, आणि एक managed state directory देते. हे एका throwaway, low-privilege identity अंतर्गत self-contained service चालवण्याची सर्वात सोपी पद्धत आहे.

non-root user म्हणून चालवणे firewall ची जागा घेते का?

नाही. ते वेगवेगळ्या गोष्टींचे संरक्षण करतात. unprivileged user म्हणून चालवणे हे service breach झाल्यास ती काय करू शकते यावर मर्यादा आणते, तर firewall कोणती service एक्सेस करू शकते यावर मर्यादा आणते. दोन्ही वापरा, आणि hardened SSH सोबत वापरा, जेणेकरून प्रत्येक स्तर इतर काय करू शकत नाही याचे संरक्षण करेल.

service user च्या मालकीच्या कोणत्या फाईल्स असाव्यात?

फक्त त्या फाईल्स ज्यांची service ला खरोखर गरज आहे, त्यापेक्षा जास्त नाही. त्या account ला स्वतःची working directory आणि डेटाची मालकी द्या, आणि बाकी सर्व गोष्टी root च्या मालकीच्या ठेवा. एक चांगली पद्धत म्हणजे application directory साठी sudo chown -R svc-app:svc-app /opt/svc-app वापरणे, तर /etc अंतर्गत असलेली configuration root च्या मालकीची राहते आणि ती फक्त service द्वारे वाचता येते. उद्दिष्ट हे आहे की जर process कधी compromise झाला, तर तो बदलू शकणाऱ्या फाईल्स त्याच्या स्वतःच्या डेटापुरत्या मर्यादित असतील, संपूर्ण सिस्टमपुरत्या नाही.