OpenVPN యొక్క user డ్రాప్‌పై systemd హార్డెనింగ్‌ను పోగు చేయవద్దు

కలిపి అతికించిన కనీస హక్కుల రెండు వంటకాలు మరింత కఠినమైన అమరికను ఇవ్వవు. ఒక నమూనా డీమన్‌ను హక్కులతో ప్రారంభమై ప్రారంభీకరణ తర్వాత హక్కులు లేని ఖాతాలోకి దిగడానికి అనుమతిస్తుంది; మరొకటి సేవా నిర్వాహకుడిని మొదటి ఆదేశం నుంచే పరిమిత గుర్తింపు కింద అమలు చేయనిస్తుంది. ప్రతి ఒక్కటి విడిగా పనిచేస్తుంది, రెండింటి కలయిక తరచుగా రెండు పనులలో ఏదీ శుభ్రంగా చేయలేని సేవను సృష్టిస్తుంది. మిగిలిన భాగం నిర్ణయాన్ని క్రమంగా చూస్తుంది.

రెండు నమూనాలు, మార్పు యొక్క ఒకే యజమాని

మొదటి నమూనా డీమన్‌ది. సంఘ OpenVPN యొక్క user మరియు group ఎంపికలు సొరంగం, కీలు సిద్ధమైన తర్వాత గుర్తింపును మారుస్తాయి, persist-key తో పాటు persist-tun ఆ వనరులను తర్వాత కూడా ఉపయోగించగలిగేలా ఉంచుతాయి.

రెండో నమూనా సేవా నిర్వాహకుడిది. systemd యొక్క User= లేదా Group= సెట్టింగ్ ప్రక్రియ ఏ గుర్తింపు కింద ప్రారంభమవుతుందో నిర్ణయిస్తుంది, సామర్థ్య ఆదేశాలు ఏమి ఉంచుకోగలదో నిర్ణయిస్తాయి. నమూనాల మధ్య ఎంపిక భద్రతా ప్రశ్న కాకముందే ప్యాకేజింగ్ ప్రశ్న, ప్యాకేజీ నిర్వాహకుడు దానికి ఇప్పటికే సమాధానం చెప్పారు. మీ పని మూడో ఎంపికను కనిపెట్టడం కాదు, ఆ సమాధానాన్ని కనుగొనడం.

రెండూ చెల్లుబాటు అవుతాయి. తప్పు ఏమిటంటే వాటిని ఒకే రూపకల్పన పొరలుగా భావించడం, ఎందుకంటే రెండో నమూనా మొదటి దాని గుర్తింపు మార్పును ప్రక్రియకు ఇక అనుమతి లేని చర్యగా మార్చగలదు.

గుర్తింపు ఎక్కడ మారుతుందో నిర్ణయించండి

యూనిట్ ఇప్పటికే ప్రత్యేక ఖాతాగా ప్రారంభమైతే, డీమన్‌కు మరో ఖాతా కావాలని ఆదేశించడం కఠినీకరించిన సేవ ఎప్పుడూ చేయకూడని setuid మార్పును కోరుతుంది. వైఫల్యం ప్రారంభంలో అనుమతి లోపంగా కనిపిస్తుంది, స్పష్టమైన విధాన సందేశంగా కాదు. ఇది తప్పిపోయిన సామర్థ్యంగా చదవబడుతుంది, ఇది ప్రజలను గుర్తింపు ప్రశ్న వైపు కాకుండా మరింత విస్తృత పరిమితి సమితి వైపు నెడుతుంది.

ఏదైనా సవరించే ముందు ఇన్‌స్టాల్ చేసిన ప్యాకేజీ నిజంగా ఏమి అందిస్తుందో చదవండి, దాని drop-in డైరెక్టరీతో సహా. కొన్ని యూనిట్లు నిర్వాహకుడు ఇప్పటికే నిర్వహిస్తున్నందున డీమన్ స్వంత దిగుమతిని ఉద్దేశపూర్వకంగా వదిలేస్తాయి, మరికొన్ని ప్రారంభీకరణ తర్వాత మార్పు కోసం ఆ ఎంపికలపై ఆధారపడతాయి. ఏ నమూనా వారసత్వంగా వచ్చిందో తెలియకుండా ఒకదాన్ని తీసేయడమే నడుస్తున్న సేవ ప్రారంభం కాకుండా చేసే మార్గం.

ఎంచుకున్న నమూనాను ఒక లైన్‌లో రాయండి: నిర్వాహక-యాజమాన్యం లేదా డీమన్-యాజమాన్యం. తర్వాతి ప్రతి ఆదేశం ఆ వాక్యంతో సరిపోలాలి, మిశ్రమ యూనిట్ రాజీగా కాకుండా లోపంగా పరిగణించాలి.

సామర్థ్యాలు పరిమితులు, దానాలు కావు

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

సామర్థ్యాన్ని సేవ యొక్క పరిసర సమితిలో నిజంగా ఉంచేది AmbientCapabilities=. systemd అమలు సూచిక రెండు ఆదేశాలను విడివిడిగా నమోదు చేస్తుంది, ఈ భేదమే ఆన్‌లైన్‌లో సామర్థ్యాలపై ఉన్న గందరగోళ సలహాలను ఎక్కువగా వివరిస్తుంది.

విఫలమవుతున్న చర్య దాన్ని గుర్తించిన తర్వాతే సామర్థ్యాన్ని జోడించండి. విస్తృత పరిమితి సమితి నిజమైన కారణాన్ని దాచి సేవను రూపకల్పన ఉద్దేశించిన దానికంటే ఎక్కువ హక్కులతో వదిలేస్తుంది. పైకప్పు ఇక పనిని వివరించనందున యూనిట్ సమీక్షను కూడా కష్టతరం చేస్తుంది. నిజమైన లోపం సరిచేసిన తర్వాత అదనపు సామర్థ్యాన్ని తీసివేయండి.

జీవిత చక్రం అంతటా అధికారాన్ని మ్యాప్ చేయండి

ప్రతి దశలో ప్రక్రియ ఏమి చేయాలో జాబితా చేయండి: ప్రారంభం, స్థిర స్థితి, పునఃప్రామాణీకరణ మరియు విడదీయడం. ఇంటర్‌ఫేస్ సృష్టి, మార్గ మార్పులు, రక్షిత కీ పఠనం మరియు సహాయకుడిని పిలవడం అన్నీ ఒకే క్షణంలో లేదా ఒకే అవసరాల కింద జరగవు. సామర్థ్యం ప్రకారం క్రమబద్ధీకరించే ముందు జాబితాను దశ ప్రకారం క్రమబద్ధీకరించండి.

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

పంచుకున్నది కాదు, ప్రత్యేక ఖాతాను ఉపయోగించండి. OpenVPN డెవలపర్లు nobody ను సాధారణ ఉదాహరణగా ఉపయోగించే అలవాటుపై హెచ్చరిస్తారు, ఎందుకంటే హోస్ట్‌లోని ఇతర సేవలు ఇప్పటికే ఆ ఖాతాలో నడుస్తూ ఉండవచ్చు, మీరు అనుకున్న వేరుపడవడం అక్కడ లేదు.

స్థానిక భారాన్ని మార్చే లక్షణాలు, ఉదాహరణకు డేటా-ఛానెల్ ఆఫ్‌లోడ్ లేదా వేరే విధంగా లింక్ అయ్యే బిల్డ్, ఏ చర్యలు అవసరమో మార్చవచ్చు. ప్యాకేజీ మారినప్పుడు మ్యాప్‌ను మళ్లీ చూడండి, ఏదో విరిగినప్పుడు మాత్రమే కాదు.

ప్రణాళికను రాసి ఉంచండి, పునరుద్ధరణ ప్రాప్యతను ఉంచుకోండి

అమరిక రికార్డు నిర్వాహకుడు, ప్రారంభ గుర్తింపు, ఉద్దేశించిన స్థిర గుర్తింపు మరియు ప్రతి మంజూరును దాన్ని అవసరపడే చర్యతో పాటు పేర్కొనాలి. ఆ రికార్డే తదుపరి మార్పును ప్రయోగంగా కాకుండా సమీక్షించదగినదిగా చేస్తుంది.

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

విజయం అంటే అర్థమైన కనీస-అధికార జీవిత చక్రం, root కాని పేరుతో యాదృచ్ఛికంగా నడుస్తున్న ప్రక్రియ కాదు.