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

Провјера аутентичности преко PAM-а може успјети када клијент покренете ручно и не успјети са AUTH_FAILED чим systemd покрене исти профил. Лозинка се не мијења између тих покретања; мијења се скуп ограничења око процеса који PAM-у поставља питање. PAM одговара преко помоћника чија је способност промјене властитих вјеродајница управо оно што очвршћена јединица уклања. Нађите тог помоћника и границу која му треба прије него што дотакнете попис способности.

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

Уз локалну провјеру аутентичности лозинком pam_unix ријетко сам чита датотеку сажетка. Извршава unix_chkpwd, који дистрибуције инсталирају као setuid root или setgid shadow како би се једна лозинка могла провјерити у име процеса који не би требао читати /etc/shadow. Уклоните могућност стицања тог идентитета и помоћник не може довршити провјеру, па модул враћа обичну погрешку провјере аутентичности.

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

Прочитајте јединицу прије него што прочитате запис лозинки

Запакирана јединица може носити drop-in који нисте написали, а стварна конфигурација је спојени резултат. Испишите јединицу како је види systemd, заједно с поставкама sandbox-а које одлучују може ли се помоћник сам подићи. Преглед само за читање довољан је у овој фази.

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

Прва наредба показује одакле долазе јединица и њезини 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. Који је извршни програм извео дјеловање, у којој је домени радио, какве се врсте мете дотакао, који је разред објекта био укључен и које је допуштење политика одбила - свако од тога сузује одговор на други начин.

Извуците одбијање из ревизијског записа

На хосту у начину 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

Исправан тунел треба и поновно повезивање, јер промјене sandbox-а кваре другу везу чешће од прве. Провјерите успостављени socket након поновног повезивања и потврдите да га иста јединица још послужује.