Linux services को unprivileged user के रूप में कैसे चलाएं

सब कुछ root के रूप में क्यों न चलाएं

Root मशीन पर कुछ भी कर सकता है: हर फाइल को पढ़ सकता है, कोई भी सेटिंग बदल सकता है, और पूरे सिस्टम को डिलीट कर सकता है। जब आप किसी service को root के रूप में चलाते हैं, तो आप वह सारी शक्ति उस service को सौंप देते हैं। यदि service में कोई ऐसी खामी है जिसका फायदा हमलावर उठा सके, तो उन्हें केवल service का एक्सेस नहीं मिलता, बल्कि उन्हें root का एक्सेस मिल जाता है, और root का मतलब पूरा सर्वर है। एक unprivileged user के रूप में चलाने से नुकसान सीमित रहता है। एक सीमित account के तहत चलने वाली service में खामी होने पर हमलावर को केवल वही एक्सेस मिलता है जो उस account के पास है, जो कि लगभग कुछ भी नहीं होना चाहिए।

यह least privilege का सिद्धांत है: सिस्टम के प्रत्येक हिस्से को केवल उतना ही एक्सेस दें जितना उसे अपना काम करने के लिए चाहिए, और उससे अधिक कुछ नहीं। किसी compromise के प्रभाव को सीमित करने के लिए यह सबसे प्रभावी आदत है, और एक आधुनिक सर्वर पर इसे लागू करने में आपका लगभग कोई खर्च नहीं होता है।

प्रत्येक service के लिए एक समर्पित account

पारंपरिक तरीका यह है कि प्रत्येक service के लिए एक अलग system user बनाया जाए, जो केवल उसी service की फाइलों का स्वामी हो और login न कर सके। एक web app के लिए system account कुछ इस तरह दिख सकता है:

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

प्रत्येक flag महत्वपूर्ण है। --system इसे एक service account बनाता है, न कि human 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 को पढ़ और लिख सकती है और disk पर कहीं और उसका कोई काम नहीं है। यदि कभी इसका exploitation होता है, तो attacker जिन फाइलों को बदल सकता है वे केवल /opt/myapp तक सीमित हैं; account अभी भी world-readable फाइलों को पढ़ सकता है, लेकिन यह system के बाकी हिस्सों को संशोधित नहीं कर सकता।

systemd को उस user के रूप में चलाने दें

एक बार जब account बन जाए, तो systemd को service उसी के रूप में चलाने के लिए कहें। unit file में, एक पंक्ति यह काम करती है:

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

User=appsvc का अर्थ है कि process root के बजाय उस account के सीमित अधिकारों (privileges) के साथ शुरू होती है। systemd के अंतर्गत application चलाने का यह सामान्य और प्रमाणित तरीका है, और जिस भी service के लिए आप unit लिखते हैं, उसके लिए ऐसा करना उचित है। यदि systemd गलत process को monitor कर रहा है, तो privileges कम करने से कोई लाभ नहीं होगा। इसलिए, यदि daemon के चुपचाप बंद होने के बाद भी unit 'active' रिपोर्ट करती है, तो जाँचें कि क्या आपने अपनी process के शुरू होने के तरीके के लिए सही Type= चुना है।

DynamicUser के साथ account को पूरी तरह से छोड़ दें

systemd एक कदम और आगे बढ़कर आपके लिए एक अस्थायी (throwaway) user बना सकता है, जो केवल service के चलने के दौरान ही मौजूद रहता है। DynamicUser=yes को set करें और आपको किसी account को manage करने की आवश्यकता नहीं होगी:

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

शुरू होने पर, systemd एक unused user ID allocate करता है; रुकने पर, यह उसे release कर देता है। service को एक private /tmp, अधिकांश filesystem का read-only view, और /var/lib/myapp के अंतर्गत एक writable state directory भी मिलती है जिसे StateDirectory= setup करके उसे सौंप देता है। SysV init के तहत ऐसा कुछ भी संभव नहीं था, जहाँ privileges को कम करना पूरी तरह से प्रत्येक service की अपनी start script पर निर्भर था, और यह कमी ही मुख्य कारण है कि distributions ने systemd को क्यों अपनाया। एक self-contained service के लिए जिसे केवल अपनी state directory की आवश्यकता है, DynamicUser=yes मजबूत isolation प्राप्त करने का सबसे आसान तरीका है, क्योंकि इसमें हमलावर के target करने के लिए कोई long-lived account होता ही नहीं है।

units को हाथ से लिखना कठिन काम है, और hardening directives को सही ढंग से लागू करना ही इसका सबसे बड़ा लाभ है। systemd service and timer guide में दिया गया generator आपके लिए इन options को भर सकता है ताकि unit पहली बार में ही सही बने।

यह बाकी सिस्टम के साथ कैसे काम करता है

Least privilege केवल एक परत है, और यह दूसरों को बदलने के बजाय उनके साथ मिलकर काम करती है। एक default-deny firewall यह नियंत्रित करता है कि सर्विस तक क्या पहुँच सकता है; सर्विस को unprivileged user के रूप में चलाने से यह नियंत्रित होता है कि breached होने पर सर्विस क्या कर सकती है; और hardened SSH हमलावरों को शुरुआत में ही सर्वर से दूर रखता है। इनमें से कोई भी अकेला काफी नहीं है, और साथ मिलकर इनका मतलब यह है कि एक सर्विस में मौजूद बग पूरे सर्वर के compromise होने का कारण नहीं बनता। सीक्रेट्स को सुरक्षित रखने वाली किसी चीज़ को होस्ट करना यह दिखाता है कि ये परतें कहाँ काम करना बंद कर देती हैं: एक restricted account यह सीमित करता है कि breached process क्या एक्सेस कर सकती है, लेकिन Vaultwarden जैसा self-hosted password manager इस बात पर निर्भर करता है कि आप उसके admin token और backup file को कैसे सुरक्षित रखते हैं, क्योंकि user isolation इन्हें कवर नहीं करता है।

आगे बढ़ने से पहले, पूरे सर्वर के लिए एक hardening checklist देखें और काम करने के लिए अपनी एक व्यक्तिगत कॉपी तैयार करें:

FAQ

मुझे किसी service को root के रूप में क्यों नहीं चलाना चाहिए?

क्योंकि root मशीन पर कुछ भी कर सकता है, यदि root के रूप में चल रही कोई service हैक हो जाती है, तो हमलावर को पूरे सर्वर का एक्सेस मिल जाता है, न कि केवल उस service का। service को एक सीमित, unprivileged account के रूप में चलाने से नुकसान केवल उस account की पहुंच तक ही सीमित रहता है। root को केवल administration के लिए सुरक्षित रखें, और हर long-running service को एक restricted user के रूप में चलाएं।

मैं ऐसा user कैसे बनाऊं जो login न कर सके?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME चलाएं। nologin shell का मतलब है कि यदि account के credentials चोरी भी हो जाएं, तो भी वह interactive session नहीं खोल सकता, --system इसे एक service account के रूप में चिह्नित करता है, और --no-create-home उस home directory को छोड़ देता है जिसकी उसे आवश्यकता नहीं है। chown के साथ इसे केवल अपनी फाइलों का स्वामित्व दें।

systemd DynamicUser क्या है?

DynamicUser=yes systemd को service के लिए एक अस्थायी user बनाने के लिए कहता है जो केवल तब तक मौजूद रहता है जब तक service चलती है, इसलिए आपको कभी भी long-lived account को manage नहीं करना पड़ता। यह service को एक private /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 कभी भी compromised हो जाए, तो जिन फाइलों को वह बदल सकती है, वे केवल उसके अपने डेटा तक सीमित हों, न कि बाकी सिस्टम तक।