సేవలను unprivileged user‌గా ఎలా నడపాలి

root గా ప్రతిదీ ఎందుకు నడపకూడదు

root ఖాతాతో యంత్రంలోని ఏదైనా చేయవచ్చు: ప్రతి ఫైల్‌ను చదవడం, ఏ సెట్టింగ్‌నైనా మార్చడం, మొత్తం system‌ను తొలగించడం. మీరు ఒక service‌ను root గా నడిపితే, ఆ service‌కు ఈ మొత్తం అధికారం ఇస్తారు. ఆ service‌లో attacker exploit చేయగల bug ఉంటే, attacker‌కు service మాత్రమే కాకుండా root అధికారం కూడా లభిస్తుంది. root అంటే మొత్తం server‌పై పూర్తి అధికారం. Unprivileged user‌గా service‌ను నడపడం వల్ల నష్టం పరిమితమవుతుంది. పరిమిత account‌తో నడిచే service‌లో bug ఉంటే, attacker‌కు ఆ account‌కు అందుబాటులో ఉన్న వాటికే ప్రాప్యత ఉంటుంది. సాధారణంగా అవి చాలా తక్కువగా ఉండాలి.

దీనినే principle of least privilege అంటారు: system‌లోని ప్రతి భాగానికి తన పని చేయడానికి అవసరమైన ప్రాప్యతను మాత్రమే ఇవ్వాలి. అంతకంటే ఎక్కువ ప్రాప్యత ఇవ్వకూడదు. Compromise వల్ల కలిగే నష్ట పరిధిని పరిమితం చేయడానికి ఇది అత్యంత ప్రభావవంతమైన అలవాటు. ఆధునిక server‌లో దీన్ని అమలు చేయడానికి దాదాపు ఎలాంటి అదనపు వ్యయం ఉండదు.

సేవకు ప్రత్యేక ఖాతా

సంప్రదాయ పద్ధతిలో ప్రతి సేవ కోసం ప్రత్యేక system user ను సృష్టిస్తారు. ఆ user కు ఆ సేవకు చెందిన files మాత్రమే ఉంటాయి. దానితో login చేయడం సాధ్యం కాదు. Web app కోసం system account ఇలా ఉండవచ్చు:

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

ప్రతి flag కు ప్రాధాన్యత ఉంది. --system దీనిని మానవ వినియోగదారు login కోసం కాకుండా service account గా రూపొందిస్తుంది. --no-create-home అవసరం లేని home directory సృష్టించడాన్ని నిలిపివేస్తుంది. --shell /usr/sbin/nologin వల్ల దాడి చేసేవారు ఎలాగైనా ఆ account ను పొందినా, దానితో shell తెరవలేరు. ఈ account ఒక process మరియు దాని files కు owner గా మాత్రమే ఉంటుంది.

తర్వాత ఆ user కు అవసరమైన files మాత్రమే ఇవ్వాలి:

sudo chown -R appsvc:appsvc /opt/myapp

ఇప్పుడు service తనకు చెందిన directory ను మాత్రమే చదివి వ్రాస్తుంది. Disk లోని ఇతర ప్రాంతాలకు దానికి పని ఉండదు. అది ఎప్పుడైనా exploit చేయబడితే, దాడి చేసేవారు మార్చగల files /opt/myapp కు మాత్రమే పరిమితమవుతాయి. World-readable files ను ఆ account చదవగలదు, కానీ system లోని మిగతా భాగాలను మార్చలదు.

systemd ఆ వినియోగదారుగా దీన్ని నడపాలి

ఖాతా సృష్టించిన తర్వాత, సేవను ఆ ఖాతాగా నడపమని systemd కు చెప్పండి. Unit file లో ఒక లైన్‌ చాలు:

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

User=appsvc వల్ల process root యొక్క హక్కులతో కాకుండా, ఆ ఖాతాకు పరిమితమైన హక్కులతో ప్రారంభమవుతుంది. systemd కింద అప్లికేషన్‌ను నడపడానికి ఇది సాధారణంగా ఉపయోగించే సరైన విధానం. మీరు unit file రాసే ప్రతి service కు దీన్ని అమలు చేయడం మంచిది. అయితే systemd తప్పు process ను పర్యవేక్షిస్తుంటే privileges తగ్గించడం ఉపయోగపడదు. Daemon నిశ్శబ్దంగా ఆగిపోయిన తర్వాత కూడా unit active గా చూపిస్తే, మీ process ప్రారంభమయ్యే విధానానికి సరైన Type= ను ఎంచుకున్నారా అని తనిఖీ చేయండి.

DynamicUser తో account ను పూర్తిగా దాటవేయడం

systemd మీ కోసం తాత్కాలిక user ను సృష్టించగలదు. ఆ user service నడుస్తున్నంతసేపు మాత్రమే ఉంటుంది. DynamicUser=yes ను సెట్ చేస్తే account నిర్వహణ అవసరం ఉండదు:

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

ప్రారంభ సమయంలో systemd ఉపయోగంలో లేని user ID ను కేటాయిస్తుంది. ఆపినప్పుడు దాన్ని తిరిగి విడుదల చేస్తుంది. service కు private /tmp కూడా లభిస్తుంది. అదనంగా filesystem లోని ఎక్కువ భాగానికి read-only view లభిస్తుంది. StateDirectory= సిద్ధం చేసి service కు అందించే /var/lib/myapp కింద writable state directory కూడా ఉంటుంది. SysV init లో ఇలాంటి విధానం సాధ్యమయ్యేది కాదు. అక్కడ privileges తగ్గించే బాధ్యత ప్రతి service యొక్క start script ఎలా రాసి ఉంటే అలా ఉండేది. ఈ లోటే distributions systemd కు మారడానికి ప్రధాన కారణాలలో ఒకటి. తన స్వంత state directory మాత్రమే అవసరమైన self-contained service కు బలమైన isolation పొందడానికి DynamicUser=yes అత్యల్ప శ్రమతో కూడిన మార్గం. ఎందుకంటే attacker లక్ష్యంగా చేసుకోగల దీర్ఘకాలిక account అసలు ఉండదు.

Units ను చేతితో రాయడం క్లిష్టంగా ఉంటుంది. Hardening directives ను సరిగ్గా అమర్చడమే ఇందులో ప్రధాన విలువ. systemd service మరియు timer guide లోని generator ఈ options ను మీ కోసం నింపగలదు. అందువల్ల unit మొదటిసారే సరిగ్గా ఉంటుంది.

మిగతా అంశాలతో ఇది ఎలా పనిచేస్తుంది

కనిష్ఠ అనుమతులు ఒక భద్రతా పొర మాత్రమే. అవి ఇతర పొరలను భర్తీ చేయకుండా, వాటితో కలిసి పనిచేస్తాయి. డిఫాల్ట్‌గా నిరాకరించే firewall సేవను ఏది చేరుకోగలదో నియంత్రిస్తుంది. సేవను అనుమతులు లేని userగా నడపడం ద్వారా, అది breach అయితే ఏమి చేయగలదో నియంత్రించవచ్చు. బలోపేతం చేసిన SSH ద్వారా దాడిచేసేవారు మొదట serverలోకి ప్రవేశించకుండా నిరోధించవచ్చు. వీటిలో ఏ ఒక్కటి మాత్రమే సరిపోదు. ఇవన్నీ కలిసి ఉపయోగించినప్పుడు, ఒక సేవలోని bug మొత్తం server compromiseగా మారకుండా నిరోధిస్తాయి. Secretsను రక్షించే ఏదైనా సేవను host చేయడం ద్వారా ఈ పొరలకు పరిమితులు ఎక్కడ ఉన్నాయో తెలుస్తుంది. Restricted account breach అయిన process ఏ వనరులను తాకగలదో పరిమితం చేస్తుంది. అయితే Vaultwarden వంటి self-hosted password manager భద్రత మాత్రం దాని admin token మరియు backup fileను మీరు ఎలా రక్షిస్తారనే దానిపై ఆధారపడి ఉంటుంది. User isolation వీటిలో దేనినీ రక్షించదు.

తదుపరి అంశానికి వెళ్లే ముందు, మొత్తం server కోసం hardening checklistను పరిశీలించి, దాని ఆధారంగా పనిచేయడానికి వ్యక్తిగతీకరించిన ప్రతిని రూపొందించండి:

FAQ

root గా సేవను ఎందుకు అమలు చేయకూడదు?

root ఖాతా యంత్రంలోని ఏదైనా చేయగలదు. root గా నడుస్తున్న సేవను దాడి చేసేవారు exploit చేస్తే, వారికి ఆ సేవ మాత్రమే కాకుండా మొత్తం సర్వర్‌పై నియంత్రణ లభిస్తుంది. పరిమిత హక్కులు కలిగిన unprivileged ఖాతాగా సేవను నడిపితే, ఆ ఖాతా యాక్సెస్ చేయగల వనరులకే నష్టం పరిమితమవుతుంది. root ను administration కోసం మాత్రమే ఉపయోగించండి. దీర్ఘకాలం నడిచే ప్రతి సేవను restricted user గా అమలు చేయండి.

login చేయలేని user ను ఎలా సృష్టించాలి?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME ను అమలు చేయండి. nologin shell వల్ల credentials దొంగిలించబడినా, ఆ ఖాతా interactive session తెరవలేరు. --system దాన్ని service account గా గుర్తిస్తుంది. --no-create-home అవసరం లేని home directory సృష్టిని నిలిపివేస్తుంది. chown తో ఆ user కు తన స్వంత files పై మాత్రమే ownership ఇవ్వండి.

systemd DynamicUser అంటే ఏమిటి?

DynamicUser=yes systemd కు ఆ service నడుస్తున్న సమయంలో మాత్రమే ఉండే తాత్కాలిక user ను సృష్టించమని చెబుతుంది. అందువల్ల దీర్ఘకాలం ఉండే account ను మీరు నిర్వహించాల్సిన అవసరం ఉండదు. ఇది service కు private /tmp, ఎక్కువగా read-only filesystem view, అలాగే నిర్వహించబడే state directory ని కూడా ఇస్తుంది. తాత్కాలిక, తక్కువ-హక్కుల identity కింద self-contained service ను నడిపించడానికి ఇది అత్యల్ప నిర్వహణ అవసరమయ్యే మార్గం.

non-root user గా నడపడం firewall కు ప్రత్యామ్నాయమా?

కాదు. ఇవి వేర్వేరు అంశాలను రక్షిస్తాయి. unprivileged user గా నడపడం వల్ల service breach అయినప్పుడు అది చేయగల పనులు పరిమితమవుతాయి. firewall వల్ల service ను అసలు ఏ network traffic చేరుకోగలదో పరిమితమవుతుంది. రెండింటినీ hardened SSH తో కలిపి ఉపయోగించండి. ఇలా ప్రతి భద్రతా పొర, ఇతర పొరలు నిరోధించలేని అంశాలను కవర్ చేస్తుంది.

service user ఏ files కు owner గా ఉండాలి?

service కు నిజంగా అవసరమైన files కు మాత్రమే, అంతకుమించి ఏవీ కాదు. ఆ account కు తన working directory మరియు data పై ownership ఇవ్వండి. మిగతా అన్నింటినీ root owner గా ఉంచండి. అప్లికేషన్ directory కోసం sudo chown -R svc-app:svc-app /opt/svc-app ఉపయోగించడం మంచి పద్ధతి. /etc కింద ఉన్న configuration మాత్రం root owner గా ఉండాలి; service దాన్ని read చేయగలిగితే చాలు. ఎప్పుడైనా process compromise అయినా, అది మార్చగల files తన data కు మాత్రమే పరిమితం కావాలి; మిగతా system కు కాదు.