Linux లో services ను unprivileged user గా రన్ చేయడం

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

root మెషీన్‌లో ఏదైనా చేయగలదు: ప్రతి ఫైల్‌ను చదవడం, ఏ సెట్టింగ్‌ను అయినా మార్చడం, మొత్తం సిస్టమ్‌ను తొలగించడం. మీరు ఒక సర్వీస్‌ను root గా రన్ చేసినప్పుడు, ఆ మొత్తం శక్తిని ఆ సర్వీస్‌కు అప్పగిస్తారు. సర్వీస్‌లో దోపిడీదారుడు ఉపయోగించగలిగే బగ్ ఉంటే, వారికి కేవలం సర్వీస్ మాత్రమే కాదు, root లభిస్తుంది, root అంటే మొత్తం సర్వర్. అన్‌ప్రివిలేజ్డ్ యూజర్ గా రన్ చేయడం నష్టాన్ని పరిమితం చేస్తుంది. పరిమిత అకౌంట్ గా రన్ అయ్యే సర్వీస్‌లో బగ్ ఉంటే, దోపిడీదారుడికి ఆ అకౌంట్ తాకగలిగేది మాత్రమే లభిస్తుంది, అది దాదాపు ఏమీ ఉండకూడదు.

ఇది కనీయ ప్రివిలేజ్ సూత్రం: సిస్టమ్‌లోని ప్రతి భాగానికి దాని పని చేయడానికి అవసరమైన యాక్సెస్ మాత్రమే ఇవ్వండి, అంతే. దోపిడీ ప్రభావ పరిధిని పరిమితం చేయడానికి ఇది అత్యంత ప్రభావవంతమైన అలవాటు, ఆధునిక సర్వర్‌లో దీన్ని ఆచరించడానికి మీకు దాదాపు ఏ ఖర్చు ఉండదు.

ప్రతి సర్వీస్‌కు ఒక ప్రత్యేక అకౌంట్

సంప్రదాయ పద్ధతి ప్రతి సర్వీస్‌కు ఒక వేరే సిస్టమ్ యూజర్‌ను సృష్టించడం, అది ఆ సర్వీస్ ఫైళ్లను మాత్రమే కలిగి ఉంటుంది మరియు లాగిన్ చేయలేదు. వెబ్ యాప్ కోసం సిస్టమ్ అకౌంట్ ఇలా కనిపిస్తుంది:

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

ప్రతి ఫ్లాగ్ ముఖ్యమైనది. --system దాన్ని మానవ లాగిన్ కాకుండా సర్వీస్ అకౌంట్‌గా చేస్తుంది. --no-create-home దానికి అవసరం లేని హోమ్ డైరెక్టరీని వదిలివేస్తుంది. --shell /usr/sbin/nologin అంటే దోపిడీదారుడు ఎలాగైనా ఆ అకౌంట్‌ను పట్టుకున్నా, వారు దానితో షెల్ తెరవలేరు. ఆ అకౌంట్ ఒక ప్రాసెస్ మరియు దాని ఫైళ్లను కలిగి ఉండటానికి మాత్రమే ఉంటుంది.

అప్పుడు ఆ యూజర్‌కు అవసరమైన ఫైళ్లను మాత్రమే ఇవ్వండి, అంతే:

sudo chown -R appsvc:appsvc /opt/myapp

ఇప్పుడు సర్వీస్ దాని స్వంత డైరెక్టరీని చదువుతుంది మరియు రాస్తుంది, డిస్క్‌లో మరెక్కడా దానికి పని ఉండదు. అది ఎప్పుడైనా దోపిడీకి గురైతే, దోపిడీదారుడు మార్చగలిగే ఫైళ్లు /opt/myapp పరిమితం; అకౌంట్ ఇంకా ప్రపంచంలో ఎవరైనా చదవగలిగే వాటిని చదవగలదు, కానీ మిగిలిన సిస్టమ్‌ను సవరించలేదు.

దాన్ని ఆ యూజర్ గా systemd రన్ చేయనివ్వండి

అకౌంట్ ఉన్నంత సేపు, సర్వీస్‌ను దాని గా రన్ చేయమని systemd కు చెప్పండి. యూనిట్ ఫైల్‌లో, ఒకే లైన్ అది చేస్తుంది:

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

User=appsvc అంటే ప్రాసెస్ root బదులుగా ఆ అకౌంట్ యొక్క పరిమిత అధికారాలతో ప్రారంభమవుతుంది. ఇది systemd కింద అప్లికేషన్‌ను రన్ చేయడానికి సాధారణ, బాగా తెలిసిన మార్గం, మీరు యూనిట్ వ్రాసే ప్రతి సర్వీస్‌కు ఇది చేయడం విలువైనది.

లేదా DynamicUser తో అకౌంట్‌ను పూర్తిగా వదిలివేయండి

systemd మరొక అడుగు ముందుకు వెళ్లి మీ కోసం ఒక తాత్కాలిక యూజర్‌ను సృష్టిస్తుంది, అది సర్వీస్ రన్ అయ్యేంత సేపు మాత్రమే ఉంటుంది. DynamicUser=yes సెట్ చేయండి మరియు మీరు అకౌంట్‌ను పూర్తిగా నిర్వహించనందునుకోవచ్చు:

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

ప్రారంభంలో, systemd ఉపయోగించని యూజర్ ID ని కేటాయిస్తుంది; ఆపివేసినప్పుడు, దాన్ని విడుదల చేస్తుంది. సర్వీస్‌కు ప్రైవేట్ /tmp, ఫైల్‌సిస్టమ్‌లో ఎక్కువ భాగం రీడ్-ఓన్లీ వ్యూ, మరియు /var/lib/myapp కింద రాయగలిగే స్టేట్ డైరెక్టరీ కూడా లభిస్తుంది, దీన్ని StateDirectory= సెటప్ చేసి అందిస్తుంది. తన స్టేట్ డైరెక్టరీ మాత్రమే అవసరమైన స్వయం-సమృద్ధ సర్వీస్‌కు, DynamicUser=yes బలమైన ఐసోలేషన్ పొందడానికి అత్యల్ప-ప్రయత్న మార్గం, ఎందుకంటే దోపిడీదారుడు లక్ష్యంగా చేసుకోవడానికి ఎటువంటి దీర్ఘకాలిక అకౌంట్ ఉండదు.

యూనిట్‌లను మాన్యువల్‌గా వ్రాయడం కష్టం, హార్డెనింగ్ డైరెక్టివ్‌లను సరిగ్గా పొందడమే ఎక్కువ విలువ. systemd సర్వీస్ మరియు టైమర్ గైడ్ లోని జనరేటర్ మీ కోసం ఈ ఆప్షన్‌లను పూరించగలదు తద్వారా యూనిట్ మొదటిసారిే సరైనదిగా ఉంటుంది.

ఇది మిగిలినవాటితో ఎలా సరిపోతుంది

కనీయ ప్రివిలేజ్ ఒక పొర, ఇది ఇతరులను భర్తీ చేయకుండా వాటితో పనిచేస్తుంది. ఒక డిఫాల్ట్-డినై ఫైర్‌వాల్ సర్వీస్‌ను చేరుకోగలిగేది నియంత్రిస్తుంది; దాన్ని అన్‌ప్రివిలేజ్డ్ యూజర్ గా రన్ చేయడం సర్వీస్ బ్రచ్ అయితే అది ఏమి చేయగలదో నియంత్రిస్తుంది; మరియు హార్డెన్డ్ SSH దోపిడీదారులను మెషీన్ నుండి దూరంగా ఉంచుతుంది. వీటిలో ఏ ఒక్కటీ సరిపోదు, మరియు కలిసి అవి ఒక సర్వీస్‌లో బగ్ మొత్తం సర్వర్ దోపిడీగా మారదని అర్థం చేస్తుంది.

మీరు ముందుకు సాగడానికి ముందు, మొత్తం మెషీన్ కోసం హార్డెనింగ్ చెక్‌లిస్ట్‌ను రన్ చేయండి మరియు పని చేయడానికి వ్యక్తిగతీకరించిన కాపీని సృష్టించండి:

FAQ

నేను ఒక సర్వీస్‌ను root గా ఎందుకు రన్ చేయకూడదు?

root మెషీన్‌లో ఏదైనా చేయగలదు కాబట్టి, root గా రన్ అయ్యే సర్వీస్ దోపిడీకి గురైతే దోపిడీదారుడికి కేవలం సర్వీస్ మాత్రమే కాకుండా మొత్తం సర్వర్ లభిస్తుంది. సర్వీస్‌ను పరిమిత, అన్‌ప్రివిలేజ్డ్ అకౌంట్ గా రన్ చేయడం నష్టాన్ని ఆ అకౌంట్ యాక్సెస్ చేయగలిగేదానికి పరిమితం చేస్తుంది. అడ్మినిస్ట్రేషన్ కోసం root ని కాపాడండి, మరియు ప్రతి దీర్ఘకాలిక సర్వీస్‌ను పరిమిత యూజర్ గా రన్ చేయండి.

లాగిన్ చేయలేని యూజర్‌ను నేను ఎలా సృష్టిస్తాను?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME రన్ చేయండి. nologin షెల్ అంటే దాని ఆధారాలు దొంగిలించబడినా కూడా అకౌంట్ ఇంటరాక్టివ్ సెషన్‌ను తెరవలేదు, --system దాన్ని సర్వీస్ అకౌంట్‌గా గుర్తిస్తుంది, మరియు --no-create-home దానికి అవసరం లేని హోమ్ డైరెక్టరీని వదిలివేస్తుంది. chown తో దాని స్వంత ఫైళ్ల యాజమాన్యాన్ని మాత్రమే ఇవ్వండి.

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

DynamicUser=yes systemd కు సర్వీస్ కోసం ఒక తాత్కాలిక యూజర్‌ను సృష్టిచమని చెబుతుంది, అది రన్ అయ్యేంత సేపు మాత్రమే ఉంటుంది, కాబట్టి మీరు ఎప్పటికీ దీర్ఘకాలిక అకౌంట్‌ను నిర్వహించరు. ఇది సర్వీస్‌కు ప్రైవేట్ /tmp, ఎక్కువగా రీడ్-ఓన్లీ ఫైల్‌సిస్టమ్ వ్యూ, మరియు నిర్వహించబడిన స్టేట్ డైరెక్టరీని కూడా ఇస్తుంది. ఇది తాత్కాలిక, లో-ప్రివిలేజ్ ఐడెంటిటీ కింద స్వయం-సమృద్ధ సర్వీస్‌ను రన్ చేయడానికి అత్యల్ప-ప్రయత్న మార్గం.

నాన్-root యూజర్ గా రన్ చేయడం ఫైర్‌వాల్‌ను భర్తీ చేస్తుందా?

లేదు. అవి వేర్వేరు విషయాలను రక్షిస్తాయి. అన్‌ప్రివిలేజ్డ్ యూజర్ గా రన్ చేయడం సర్వీస్ బ్రచ్ అయితే అది ఏమి చేయగలదో పరిమితం చేస్తుంది, అదే ఫైర్‌వాల్ సర్వీస్‌ను చేరుకోగలిగేది పరిమితం చేస్తుంది. హార్డెన్డ్ SSH తో పాటు రెండింటినీ ఉపయోగించండి, తద్వారా ప్రతి పొర ఇతరులు చేయలేని వాటిని భర్తీ చేస్తుంది.

సర్వీస్ యూజర్ ఏ ఫైళ్లను కలిగి ఉండాలి?

సర్వీస్ నిజంగా అవసరమైన ఫైళ్లను మాత్రమే, అంతే. అకౌంట్‌కు దాని స్వంత వర్కింగ్ డైరెక్టరీ మరియు దాని డేటా యాజమాన్యాన్ని ఇవ్వండి, మరియు మిగిలిన ప్రతిదాన్ని root కలిగి ఉండేలా వదిలివేయండి. ఒక మంచి ప్యాటర్న్ అప్లికేషన్ డైరెక్టరీ కోసం sudo chown -R svc-app:svc-app /opt/svc-app, అదే సమయంలో /etc కింద ఉన్న కాన్ఫిగరేషన్ root యాజమాన్యంలో ఉంటుంది మరియు సర్వీస్ చదవగలిగేది మాత్రమే. లక్ష్యం ఏమిటంటే ప్రాసెస్ ఎప్పుడైనా దోపిడీకి గురైతే, అది మార్చగలిగే ఫైళ్లు దాని స్వంత డేటాకు పరిమితం, మిగిలిన సిస్టమ్‌కు కాదు.