PAM ప్రామాణీకరణ చేతితో పనిచేస్తుంది కానీ OpenVPN సేవగా విఫలమవుతుంది

PAM ద్వారా ప్రామాణీకరణ క్లయింట్ను చేతితో నడిపినప్పుడు విజయవంతం కావచ్చు, systemd అదే ప్రొఫైల్ను ప్రారంభించినప్పుడు AUTH_FAILED తో విఫలమవుతుంది. ఆ రన్ల మధ్య పాస్వర్డ్ మారదు; మారేది PAMను ప్రశ్న అడిగే ప్రక్రియ చుట్టూ ఉన్న పరిమితుల సమితి. PAM తన స్వంత ఆధారాలను మార్చుకునే సామర్థ్యం కఠినీకృత unit తొలగించేది సరిగ్గా అదే అయిన సహాయకుడి ద్వారా సమాధానం ఇస్తుంది. సామర్థ్యాల జాబితాను తాకే ముందు ఆ సహాయకుడిని మరియు అతనికి అవసరమైన సరిహద్దును కనుగొనండి.

unix_chkpwd అనేది PAM ప్రశ్నకు సమాధానం ఇచ్చే బైనరీ

స్థానిక పాస్వర్డ్ ప్రామాణీకరణతో, pam_unix hash ఫైల్ను అరుదుగా తానే చదువుతుంది. ఇది unix_chkpwd ను అమలు చేస్తుంది, /etc/shadow చదవకూడని ప్రక్రియ తరఫున ఒక పాస్వర్డ్ను తనిఖీ చేయగలిగేలా పంపిణీలు దాన్ని setuid root లేదా setgid shadowగా ఇన్స్టాల్ చేస్తాయి. ఆ గుర్తింపును పొందే సామర్థ్యాన్ని తీసివేయండి, సహాయకుడు తనిఖీని పూర్తి చేయలేడు, కాబట్టి మాడ్యూల్ సాధారణ ప్రామాణీకరణ వైఫల్యాన్ని తిరిగి ఇస్తుంది.

అప్పుడు వైఫల్యం క్లయింట్ చూడగల ప్రతి లాగ్లో ఆధారాల సమస్యలా కనిపిస్తుంది. అదే ఉచ్చు: క్లయింట్ PAM తనకు చెప్పినది నివేదిస్తుంది, PAM మాత్రం స్టాక్ లేదు అని చెప్పిందని నివేదిస్తుంది. rootగా సహాయకుడిని చేతితో నడపడం కూడా ఏమీ నిరూపించదు, ఎందుకంటే అది సేవ ఎప్పుడూ ఉపయోగించని అధికార మార్గాన్ని వినియోగిస్తుంది. systemd నిజంగా లోడ్ చేసిన unitను చదవండి, ఆపై చేసిన ప్రయత్నం కోసం సిస్టమ్ లాగ్ను చదవండి. ఆ రెండు దృశ్యాలు sandbox సమస్యను తప్పు పాస్వర్డ్ సమస్య నుండి వేరు చేస్తాయి.

పాస్వర్డ్ లాగ్ చదవడానికి ముందు unitను చదవండి

ప్యాకేజీ చేసిన unit మీరు రాయని drop-inను కలిగి ఉండవచ్చు, ప్రభావవంతమైన కాన్ఫిగరేషన్ కలిపిన ఫలితం. systemd చూసే విధంగా unitను, సహాయకుడు తనను తాను పెంచుకోగలదా అని నిర్ణయించే sandbox సెట్టింగ్లతో పాటు ముద్రించండి. ఈ దశలో చదవడం-మాత్రమే తనిఖీ సరిపోతుంది.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

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

మీరు చూసేదాన్ని అదే పంపిణీ మరియు వెర్షన్ పనిచేసే హోస్ట్తో పోల్చండి. User, CapabilityBoundingSet లేదా NoNewPrivileges లోని తేడా ఒక నిర్దిష్ట ఆధారం; గద్య వ్యాఖ్యలలోని తేడా కాదు. ఏదైనా మార్చే ముందు విలువలను రాసుకోండి, ఎందుకంటే కదిలే లక్ష్యంతో తర్వాతి పోలిక ఏమీ నిరూపించదు. సేవ అధికారాలు లేని ఖాతాగా ఖాళీ సరిహద్దు సమితితో నడిస్తే, సహాయకుడికి పని చేయడానికి దాదాపు ఏమీ ఉండదు.

ఆధార మార్పిడి, ఫైల్ యాక్సెస్ మరియు విధానం మూడు సరిహద్దులు

exec సమయంలో ఏమి జరుగుతుందో దానితో ప్రారంభించండి. setuid బైనరీ లేదా file capabilities ఉన్న ఫైల్ ఆధార మార్పిడిని రేకెత్తిస్తుంది, కాబట్టి ఏర్పడే గుర్తింపు పిలిచినవారి కొనసాగింపు కాదు. సరిహద్దు సమితి అలాంటి బైనరీ పొందగలిగేదాన్ని పరిమితం చేస్తుంది, NoNewPrivileges setuid, setgid మరియు file capabilities పొందడాన్ని పూర్తిగా నిరోధిస్తుంది. ఆ మూడింటిలో ఏదైనా సహాయకుడిని ఆపగలదు, సేవలోని మిగతా ప్రతి పని చెక్కుచెదరకుండా ఉంటుంది.

తర్వాత, విస్తృత విచక్షణాత్మక బైపాస్ను ఇరుకైన పఠన యాక్సెస్ నుండి వేరు చేయండి. CAP_DAC_OVERRIDE దాదాపు ప్రతిచోటా విచక్షణాత్మక తనిఖీలను దాటవేస్తుంది, CAP_DAC_READ_SEARCH తన స్వంత అదనపు అధికారాలతో పఠనం మరియు డైరెక్టరీ ట్రావెర్సల్ను కవర్ చేస్తుంది. ఇవి వేర్వేరు ప్రభావ పరిధులు ఉన్న వేర్వేరు సాధనాలు, వాటిలో ఏదీ PAM shadow ఫైల్ను చదవనివ్వండి అని రాయడం కాదు.

చివరగా, తప్పనిసరి విధానం ఈ చర్యను అనుమతిస్తుందా అని అడగండి. Linux సామర్థ్యం SELinuxను భర్తీ చేయదు, దాన్ని కలిగి ఉండటం రకం అమలు నియమం గురించి ఏమీ నిరూపించదు. ఫైల్ యాక్సెస్ నిరాకరణ మరియు సామర్థ్య నిరాకరణను వేర్వేరు సాక్ష్యాలుగా పరిగణించండి, ఎందుకంటే అవి వేర్వేరు సరిదిద్దుడులను మరియు తరచుగా వేర్వేరు యజమానులను సూచిస్తాయి. denied అనే ఒక్క పదానికి బదులు నివేదికలోని ప్రతి ఫీల్డ్ను చదవండి. ఏ executable చర్య చేసింది, ఏ domainలో నడిచింది, ఏ రకమైన లక్ష్యాన్ని తాకింది, ఏ వర్గపు ఆబ్జెక్ట్ పాల్గొంది మరియు విధానం ఏ అనుమతిని తిరస్కరించింది - వీటిలో ప్రతిదీ సమాధానాన్ని వేరే విధంగా సన్నగిల్చుతుంది.

తిరస్కరణను ఆడిట్ లాగ్ నుండి బయటకు తీయండి

enforcing మోడ్లో ఉన్న హోస్ట్లో, ఆడిట్ జాడ నిరాకరణను నమోదు చేసే ఏకైక ప్రదేశం. ఇటీవలి సంఘటనలను అడగండి మరియు మీరు దర్యాప్తు ప్రారంభించిన సమయంతో కాదు, విఫలమైన లాగిన్ యొక్క టైమ్స్టామ్ప్తో పోల్చి చదవండి.

ausearch -m AVC,USER_AVC -ts recent

ఖాళీ ఫలితం నిర్దోషత్వానికి సాక్ష్యం కాదు. అది ఆడిట్ సేకరించడం లేదని లేదా మీ విండో ప్రయత్నాన్ని కోల్పోయిందని అర్థం, మరియు విధానాన్ని మినహాయించే ముందు రెండు అవకాశాలను మినహాయించాలి.

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

ఒక ఆమోదించబడిన మరియు ఒక తిరస్కరించబడిన లాగిన్తో మార్పును నిరూపించండి

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

నిజమైన కనెక్షన్ ప్రయత్నం చేసి వెంటనే journalను చదవండి. సరిదిద్దుడును నిరూపించే పంక్తి ఆ ప్రయత్నానికి సంబంధించిన pam_unix(openvpn:auth) నమోదు: అది ప్రామాణీకరణ విజయం అని చెప్పాలి, ఏ AVC నమోదు కూడా అదే సెకనును కలిగి ఉండకూడదు.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

పనిచేసే tunnelకు తిరిగి కనెక్ట్ కూడా అవసరం, ఎందుకంటే sandbox మార్పులు రెండవ కనెక్షన్ను మొదటి దాని కంటే ఎక్కువగా విరగ్గొడతాయి. తిరిగి కనెక్ట్ అయిన తర్వాత ఏర్పాటైన socketను తనిఖీ చేసి, అదే unit ఇంకా దానికి సేవ చేస్తోందని నిర్ధారించండి.