Services ko unprivileged user se kaise chalayein

Sab kuch root ke roop mein kyun nahi chalana chahiye

Root machine par kuch bhi kar sakta hai: har file padh sakta hai, koi bhi setting badal sakta hai, aur poore system ko delete kar sakta hai. Jab aap kisi service ko root ke roop mein chalate hain, toh aap us service ko wo saari shakti de dete hain. Agar service mein koi bug hai jiska attacker fayda utha sake, toh unhe sirf service nahi milti, balki root mil jata hai, aur root ka matlab hai poora server. Ek unprivileged user ke roop mein chalane se nuksan simit rehta hai. Ek limited account ke roop mein chalne wali service mein bug hone par attacker ko sirf wahi cheezein milti hain jinhe wo account touch kar sakta hai, jo ki lagbhag kuch nahi hona chahiye.

Yahi least privilege ka principle hai: system ke har hisse ko sirf wahi access dein jo uske kaam ke liye zaroori hai, usse zyada nahi. Compromise ke blast radius ko kam karne ke liye ye sabse prabhavshali aadat hai, aur ek modern server par ise lagu karne mein lagbhag koi kharch nahi aata.

Har service ke liye ek dedicated account

Classic approach ye hai ki har service ke liye ek alag system user banaya jaye, jo sirf us service ki files ka maalik ho aur login na kar sake. Ek web app ke liye system account aisa dikh sakta hai:

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

Har flag mahatvapurn hai. --system ise ek service account banata hai, na ki human login. --no-create-home us home directory ko skip karta hai jiski ise zaroorat nahi hai. --shell /usr/sbin/nologin ka matlab hai ki agar attacker kisi tarah account ka kabza kar bhi le, toh wo iske saath shell nahi khol sakta. Ye account sirf ek process aur uski files ka maalik banne ke liye hota hai.

Phir us user ko sirf wahi files dein jo use chahiye, usse zyada nahi:

sudo chown -R appsvc:appsvc /opt/myapp

Ab service apne hi directory ko read aur write kar sakti hai aur disk par kahin aur iska koi kaam nahi hai. Agar ise kabhi exploit kiya jata hai, toh attacker dwara badli jane wali files /opt/myapp tak simit hain; account ab bhi sab kuch padh sakta hai jo world-readable ho, lekin ye baaki system ko modify nahi kar sakta.

systemd ko ise us user ke roop mein chalne dein

Ek baar account ban jane ke baad, systemd ko use us user ke roop mein service chalane ke liye kahein. Unit file mein, ek line ye kaam karti hai:

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

User=appsvc ka matlab hai ki process root ke bajaye us account ke limited privileges ke saath shuru hota hai. systemd ke tahat application chalane ka ye ek normal aur sahi tarika hai, aur aap har us service ke liye ise karna chahiye jiske liye aap unit likhte hain.

Ya DynamicUser ke saath account ko poori tarah skip karein

systemd ek kadam aur aage ja sakta hai aur aapke liye ek throwaway user bana sakta hai, jo sirf tab tak rehta hai jab tak service chal rahi hoti hai. DynamicUser=yes set karein aur aapko kisi account ko manage karne ki zaroorat nahi hai:

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

Shuruat mein, systemd ek unused user ID allocate karta hai; stop karte waqt, ye use release kar deta hai. Service ko ek private /tmp bhi milta hai, jo filesystem ka ek read-only view hai, aur /var/lib/myapp ke tahat ek writable state directory milti hai jise StateDirectory= setup aur hand over karta hai. Ek self-contained service ke liye jise sirf apni state directory ki zaroorat hai, DynamicUser=yes mazboot isolation pane ka sabse aasaan tarika hai, kyunki attacker ke liye koi long-lived account hota hi nahi hai.

Units ko haath se likhna mushkil hai, aur hardening directives ko sahi tarike se set karna hi sabse zyada mahatvapurn hai. the systemd service and timer guide mein generator in options ko aapke liye bhar sakta hai taaki unit pehli baar mein hi sahi ho.

Ye baaki cheezon ke saath kaise kaam karta hai

Least privilege ek layer hai, aur ye dusri layers ko replace karne ke bajaye unke saath kaam karta hai. Ek default-deny firewall ye control karta hai ki service tak kya pahunch sakta hai; ise unprivileged user ke roop mein chalana ye control karta hai ki breach hone par service kya kar sakti hai; aur hardened SSH attackers ko shuruat mein hi box se door rakhta hai. Inme se koi bhi akela kaafi nahi hai, aur saath milkar inka matlab hai ki ek service mein bug hone se poore server ka compromise nahi hota.

Aage badhne se pehle, poore box ke liye ek hardening checklist chalaein aur kaam karne ke liye ek personalised copy generate karein:

FAQ

Mujhe service ko root ke roop mein kyun nahi chalana chahiye?

Kyunki root machine par kuch bhi kar sakta hai, root ke roop mein chalne wali service agar exploit ho jati hai, toh attacker ko sirf service nahi balki poora server mil jata hai. Service ko ek limited, unprivileged account ke roop mein chalana nuksan ko sirf us cheez tak simit kar deta hai jise wo account access kar sakta hai. Root ko administration ke liye rakhein, aur har long-running service ko ek restricted user ke roop mein chalayein.

Main aisa user kaise banau jo login na kar sake?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME chalayein. nologin shell ka matlab hai ki account interactive session nahi khol sakta bhale hi uske credentials chori ho jayein, --system ise ek service account ke roop mein mark karta hai, aur --no-create-home us home directory ko skip karta hai jiski ise zaroorat nahi hai. chown ke saath ise sirf iski apni files ka maalik banayein.

systemd DynamicUser kya hai?

DynamicUser=yes systemd ko service ke liye ek temporary user banane ke liye kehta hai jo sirf tab tak rehta hai jab tak service chal rahi hoti hai, taaki aapko kabhi bhi long-lived account manage na karna pade. Ye service ko ek private /tmp, ek mostly read-only filesystem view, aur ek managed state directory bhi deta hai. Ye ek throwaway, low-privilege identity ke tahat self-contained service chalane ka sabse aasaan tarika hai.

Kya non-root user ke roop mein chalana firewall ki jagah le leta hai?

Nahi. Ve alag-alag cheezon ki raksha karte hain. Unprivileged user ke roop mein chalna ye limit karta hai ki breach hone par service kya kar sakti hai, jabki firewall ye limit karta hai ki service tak kya pahunch sakta hai. Dono ka upyog karein, hardened SSH ke saath, taaki har layer us cheez ko cover kare jise dusri nahi kar sakti.

Service user ko kin files ka maalik hona chahiye?

Sirf wahi files jinki service ko vastav mein zaroorat hai, usse zyada nahi. Account ko uski apni working directory aur uske data ka maalik banayein, aur baaki sab kuch root ke maalik rehne dein. Ek accha pattern application directory ke liye sudo chown -R svc-app:svc-app /opt/svc-app hai, jabki /etc ke tahat configuration root ke maalik rehti hai aur sirf service dwara padhi ja sakti hai. Lakshya ye hai ki agar process kabhi compromise ho jaye, toh jo files wo badal sakta hai wo uske apne data tak simit hon, na ki poore system tak.