Автентикацијата со PAM работи рачно, но не успева како услуга на OpenVPN

Автентикацијата преку PAM може да успее кога клиентот го стартувате рачно и да не успее со AUTH_FAILED штом systemd ја стартува истата профилација. Лозинката не се менува меѓу тие стартувања; она што се менува е множеството ограничувања околу процесот што му го поставува прашањето на PAM. PAM одговара преку помошна програма чија способност да ги менува сопствените акредитиви е токму она што го отстранува зајакнатата unit. Најдете ја таа помошна програма и границата што ѝ е потребна пред да допрете список со можности.

unix_chkpwd е бинарната датотека што одговара на прашањето на PAM

Со локална автентикација со лозинка pam_unix ретко ја чита самата hash-датотека. Ја извршува unix_chkpwd, која дистрибуциите ја инсталираат како setuid root или setgid shadow за да може една лозинка да се провери во име на процес што нема што да прави со читање на /etc/shadow. Отстранете ја можноста да се добие тој идентитет и помошната програма не може да ја заврши проверката, па модулот враќа обичен неуспех на автентикација.

Неуспехот потоа изгледа како проблем со акредитиви во секој дневник што клиентот може да го види. Тоа е стапицата: клиентот известува што му кажал PAM, а PAM известува само дека стекот кажал не. Стартувањето на помошната програма рачно како root исто така не докажува ништо, зашто ја вежба патеката на привилегии што услугата никогаш не ја користи. Прочитајте ја unit што systemd навистина ја вчитал, потоа системскиот дневник за обидот што го направил. Тие два погледа го одвојуваат проблемот со песочникот од проблемот со погрешна лозинка.

Прочитајте ја unit пред да го прочитате дневникот за лозинки

Спакуваната unit може да носи drop-in што не сте го напишале, а ефективната конфигурација е споениот резултат. Испечатете ја unit како што ја гледа systemd, заедно со поставките на песочникот што одлучуваат дали помошната програма може сама да се подигне. Во оваа фаза доволна е проверка само за читање.

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, што е важно зашто препишување додадено пред месеци живее подолго од сеќавањето зошто постои. Втората ги печати вредностите на песочникот од кои зависат следните два дела.

Споредете го она што го гледате со исправен домаќин од истата дистрибуција и верзија. Разликата во User, CapabilityBoundingSet или NoNewPrivileges е конкретна трага; разликата во прозните коментари не е. Запишете ги вредностите пред да смените нешто, зашто подоцнежната споредба со движечка цел не докажува ништо. Ако услугата работи со непривилегирана сметка и празно bounding-множество, помошната програма нема речиси ништо со што да работи.

Трансформацијата на акредитиви, пристапот до датотеки и политиката се три граници

Започнете со она што се случува за време на exec. setuid бинарна датотека или датотека со датотечни можности предизвикува трансформација на акредитиви, па добиениот идентитет не е продолжение на повикувачот. Bounding-множеството ограничува што може да стекне таква датотека, а NoNewPrivileges целосно го блокира стекнувањето setuid, setgid и датотечни можности. Која било од тие три може да ја запре помошната програма додека сите други функции на услугата остануваат недопрени.

Потоа одвојте широкото дискреционо заобиколување од тесниот пристап за читање. CAP_DAC_OVERRIDE ги прескокнува дискреционите проверки речиси насекаде, додека CAP_DAC_READ_SEARCH покрива читање и минување низ директориуми со свои дополнителни овластувања. Тие се различни алатки со различен радиус на дејство и ниту една не е правопис на „нека PAM ја прочита shadow-датотеката“.

На крајот прашајте дали задолжителната политика воопшто ја дозволува дејството. Linux-можност не го надвладува SELinux и поседувањето една не докажува ништо за правило за type enforcement. Третирајте го одбивањето пристап до датотека и одбивањето можност како различни докази, зашто тие именуваат различни поправки и често различни сопственици. Прочитајте го секое поле од записот, а не само зборот denied. Која извршна датотека го извршила дејството, во кој домен работела, каков тип цел допрела, која класа објект била вклучена и кое дозвола го одбила политиката — секое на свој начин го стеснува одговорот.

Извлечете го одбивањето од ревизорскиот дневник

На домаќин во режим на спроведување, ревизорската трага е единственото место што забележува одбивање. Побарајте ги неодамнешните настани и читајте ги спрема временската ознака на неуспешната најава, а не спрема времето кога почнавте истрагата.

ausearch -m AVC,USER_AVC -ts recent

Празниот резултат не е доказ за невиност. Тоа значи или дека ревизијата не собира, или дека вашиот прозорец го пропуштил обидот, и двете можности мора да се исклучат пред да ја исклучите политиката.

Упатството на Red Hat за решавање проблеми со SELinux ги става проверките на ознаките и конфигурацијата пред генерирањето allow-правила, што е правилниот редослед и за овој проблем. Погрешно означена помошна бинарна датотека и празнина во политиката даваат слични одбивања, но бараат различни поправки. Генерирањето allow-правило за грешка во означувањето го крие дефектот и му остава на следното ажурирање на пакетот повторно да го внесе. Потврдете ја ознаката на инсталираната помошна програма пред да напишете каква било политика.

Докажете ја промената со една прифатена и една одбиена најава

Сменете ја само границата што ја покажавте, потоа испробајте ги двата исхода. Сметката што треба да се автентицира мора да успее, а сметката со погрешна лозинка мора се уште да не успее. Промената што го прави секој обид успешен ја отстранила автентикацијата наместо да ја поправи.

Направете вистински обид за врска и веднаш потоа прочитајте го дневникот. Редот што ја докажува поправката е записот pam_unix(openvpn:auth) за тој обид: треба да пишува успешна автентикација и ниту еден запис AVC не смее да ја носи истата секунда.

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

Работниот тунел бара и повторно поврзување, зашто промените во песочникот почесто ја кршат втората врска отколку првата. Проверете го воспоставениот сокет по повторното поврзување и потврдете дека истата unit се уште го опслужува.