VPN ధృవపత్రాన్ని తరలించడం దాని SELinux లేబుల్ను ఎందుకు విచ్ఛిన్నం చేస్తుంది

ధృవపత్రాలు సరైన డైరెక్టరీలో చదవగల మోడ్ మరియు root యాజమాన్యంతో ఉండవచ్చు, మరియు సేవ ఇప్పటికీ ఫైల్ తెరవలేమని నివేదించవచ్చు. SELinux వ్యవస్థలో ఆ కలయిక అనుమతులను కాకుండా ఒక నిర్దిష్ట యంత్రాంగాన్ని సూచిస్తుంది. లేబుల్ ఫైల్తో పాటు ప్రయాణించింది, ఎందుకంటే పేరు మార్పు కొత్త వస్తువును సృష్టించదు. inode పాత మార్గంలో ఉన్న భద్రతా సందర్భాన్ని నిలుపుకుంది, కొత్త మార్గం విధానానికి తన స్వంత సందర్భాన్ని కేటాయించే అవకాశం ఎప్పుడూ రాలేదు.

పేరు మార్పు లేబుల్తో నిజంగా ఏమి చేస్తుంది

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

కాపీ చేయడం భిన్నంగా ప్రవర్తిస్తుంది. కాపీ గమ్యస్థాన డైరెక్టరీలో కొత్త inode సృష్టిస్తుంది, విధానం ఆ డైరెక్టరీ రకం నుండి సందర్భాన్ని కేటాయిస్తుంది, కాబట్టి కాపీ చేసిన ధృవపత్రం సాధారణంగా సరైన లేబుల్ పొందుతుంది, తరలించినది తప్పుగానే ఉంటుంది. ఆ ఒక్క భేదమే ఈ రకమైన టికెట్లలో ఎక్కువ గందరగోళాన్ని వివరిస్తుంది.

ఫైల్ సిస్టమ్ల మధ్య తరలింపు కాపీ అర్థశాస్త్రం వైపు తిరిగి వెళ్తుంది, కాబట్టి అదే ఆదేశం రెండు మెషీన్లలో /etc తన స్వంత వాల్యూమ్లో ఉందా అనే దానిపై ఆధారపడి భిన్నంగా ప్రవర్తించవచ్చు. సాధనం నమ్మదగినది కాదని నిర్ధారించే ముందు ఇది తనిఖీ చేయండి. mount పట్టికపై ఒక చూపు మీరు ఏ రకమైన తరలింపు చేశారో చెబుతుంది.

ప్రస్తుత లేబుల్ను ఆశించిన దానితో పోల్చి చదవండి

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

తర్వాత భేదాన్ని నిజమైన నిరాకరణతో అనుసంధానించండి. అసమానత తప్పు లేబుల్కు సాక్ష్యం, సేవ దాని వల్ల విఫలమైందని రుజువు కాదు, లాగ్లో సంబంధిత నిరాకరణ లేకుండా వర్తించిన సవరణ అదనపు దశలతో కూడిన ఊహ.

మినహాయింపును కల్పించడం బదులు మ్యాపింగ్ను పునరుద్ధరించండి

ప్రామాణిక స్థానానికి విధానం ఇప్పటికే మార్గాన్ని మ్యాప్ చేస్తుంది, కాబట్టి restorecon దాన్ని వర్తింపజేస్తుంది మరియు పని పూర్తవుతుంది. పరిధిని మీరు సరిచేస్తున్న డైరెక్టరీకి పరిమితం చేయండి; మొత్తం ఫైల్ సిస్టమ్ను మళ్లీ లేబుల్ చేయడం నెమ్మదైనది, ఆటంకపరిచేది, అది అసలు పొరపాటును చాలా పెద్ద మార్పు కింద పాతిపెడుతుంది.

అనుకూల డైరెక్టరీకి క్రమం ముఖ్యం, దాన్ని తిరగబెట్టడం ఏమీ మార్చకుండా విజయాన్ని నివేదించే ఆదేశాన్ని ఇస్తుంది. మ్యాపింగ్ విధానానికి చెందుతుంది, మళ్లీ లేబులింగ్ ముగింపుకు చెందుతుంది, పొడి పరుగు రెండింటికీ ముందు చెందుతుంది. ఆ చివరి భాగాన్ని దాటవేయడమే ఎప్పుడూ తప్పుగా లేని మార్గం కూడా మళ్లీ లేబుల్ అయ్యే మార్గం.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon మ్యాపింగ్ను వర్తింపజేస్తుంది; ఒకటి కల్పించలేదు. ఏ నియమం మార్గాన్ని వివరించకపోతే, పునరుద్ధరించడానికి ఏమీ లేదు, అందుకే మళ్లీ లేబులింగ్కు ముందు శాశ్వత మ్యాపింగ్ ఉండాలి. ఏ కాన్ఫిగరేషన్ ఆ మ్యాపింగ్ను కలిగి ఉందో నమోదు చేయండి, ఎందుకంటే లేకపోతే తర్వాత తరలింపు, ప్యాకేజీ నవీకరణ లేదా మళ్లీ లేబులింగ్ లోపాన్ని మళ్లీ సృష్టిస్తాయి మరియు తదుపరి వ్యక్తి సున్నా నుండి ప్రారంభిస్తాడు.

chcon ఎందుకు పరిష్కారం కాదు

chcon సందర్భాన్ని నేరుగా ఫైల్పై రాస్తుంది. అది తక్షణమే అమలవుతుంది మరియు అందుబాటులో ఉన్న అత్యంత తక్కువ నిలకడైన ఎంపిక, ఎందుకంటే ఫైల్ సిస్టమ్ మళ్లీ లేబులింగ్ విధానాన్ని మళ్లీ వర్తింపజేస్తుంది మరియు అడగకుండా చేతితో చేసిన మార్పులను పారేస్తుంది. ఫైల్ సరిచేయబడినట్లు కనిపిస్తుంది, సరిచేయడానికి ఎవరూ రాయని గడువు తేదీ ఉంది. దానికి బదులుగా మీకు మార్గాన్ని వివరించే నియమం కావాలి, అక్కడికి వచ్చే ప్రతి ఫైల్ స్వయంచాలకంగా అదే చికిత్సను పొందుతుంది.

అంతకంటే దారుణంగా, ఇది తప్పు పాఠాన్ని నేర్పుతుంది: మూల మ్యాపింగ్ ఇంకా లేదు, కాబట్టి లోపం వారాల తర్వాత స్పష్టమైన ట్రిగ్గర్ మరియు ఆ దారి మళ్లింపు గుర్తు లేకుండా తిరిగి వస్తుంది. chcon ను పరికల్పనను నిర్ధారించడానికి తాత్కాలిక ప్రయోగంగా మాత్రమే ఉపయోగించండి, తర్వాత దాన్ని తదుపరి మళ్లీ లేబులింగ్ను తట్టుకునే మ్యాపింగ్తో భర్తీ చేయండి, మరియు భర్తీ నిజంగా స్థానంలో ఉందా అని తనిఖీ చేయండి.

లేబుల్ సరిగ్గా ఉన్నప్పుడు మరియు యాక్సెస్ ఇంకా విఫలమైనప్పుడు

పేరెంట్ డైరెక్టరీలతో ప్రారంభించండి. మార్గం యొక్క ప్రతి భాగంలో ట్రావర్సల్ అనుమతి తనిఖీ చేయబడుతుంది, కాబట్టి సేవ ప్రవేశించలేని డైరెక్టరీలో సరిగ్గా లేబుల్ చేసిన ధృవపత్రం కూడా చదవలేనిదిగానే ఉంటుంది. SELinux మరియు సాధారణ అనుమతి రెండూ ప్రతి అడుగును అనుమతించాలి, ఒకదాన్ని సరిచేయడం మరొకదాన్ని సరిచేయదు.

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

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