Удостоверяването чрез PAM работи на ръка, но се проваля като услуга на OpenVPN

Удостоверяването през PAM може да успее, когато стартирате клиента на ръка, и да се провали с AUTH_FAILED, щом systemd стартира същия профил. Паролата не се променя между тези стартирания; променя се наборът от ограничения около процеса, който задава въпроса на PAM. PAM отговаря чрез помощна програма, чиято способност да сменя собствените си идентификационни данни е точно това, което премахва затегнатият unit. Намерете тази помощна програма и границата, която ѝ е нужна, преди да пипате списък с capabilities.

unix_chkpwd е двоичният файл, който отговаря на въпроса на PAM

При локално удостоверяване с парола pam_unix рядко чете самия файл с хешове. Той изпълнява unix_chkpwd, който дистрибуциите инсталират като setuid root или setgid shadow, за да може една парола да бъде проверена от името на процес, който няма работа да чете /etc/shadow. Махнете възможността да се придобие тази идентичност и помощната програма не може да завърши проверката, затова модулът връща обикновен отказ за удостоверяване.

Тогава грешката изглежда като проблем с идентификационните данни във всеки журнал, който клиентът вижда. Това е капанът: клиентът съобщава какво му е казала PAM, а PAM съобщава само, че стекът е казал не. Ръчното стартиране на помощната програма като root също не доказва нищо, защото изпробва път на привилегии, който услугата никога не използва. Прочетете unit, който systemd действително е заредил, след това системния журнал за направения опит. Тези два погледа разделят проблем със sandbox от проблем с грешна парола.

Прочетете unit, преди да четете журнала за пароли

Пакетиран unit може да носи drop-in, който не сте писали, а ефективната конфигурация е обединеният резултат. Отпечатайте unit както го вижда 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

Първата команда показва откъде идват unit и неговите drop-in, което е важно, защото добавено преди месеци override живее по-дълго от паметта защо съществува. Втората отпечатва стойностите на sandbox, от които зависят следващите два раздела.

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

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

Започнете с това, което се случва по време на exec. setuid двоичен файл или файл с файлови capabilities предизвиква трансформация на идентификационните данни, така че получената идентичност не е продължение на извикващия. Bounding наборът ограничава какво може да придобие такъв файл, а NoNewPrivileges блокира напълно придобиването на setuid, setgid и файлови capabilities. Всяко едно от тези три може да спре помощната програма, като остави всяка друга функция на услугата непокътната.

След това отделете широкото дискреционно заобикаляне от тесния достъп за четене. CAP_DAC_OVERRIDE прескача дискреционните проверки почти навсякъде, докато CAP_DAC_READ_SEARCH покрива четене и обхождане на директории със свои допълнителни правомощия. Това са различни инструменти с различен радиус на действие и нито един от тях не е изписване на „нека PAM чете shadow файла“.

Накрая попитайте дали задължителната политика изобщо разрешава действието. Linux capability не отменя SELinux и притежаването ѝ не доказва нищо за правило за type enforcement. Третирайте отказа за достъп до файл и отказа за capability като различни доказателства, защото те назовават различни поправки и често различни собственици. Четете всяко поле на записа, а не само думата denied. Кой изпълним файл е извършил действието, в кой домейн е работил, какъв тип цел е докоснал, какъв клас обект е участвал и кое разрешение е отказала политиката — всяко стеснява отговора по свой начин.

Извадете отказа от одитния журнал

На хост в режим на налагане одитната следа е единственото място, което записва отказ. Заявете последните събития и ги четете спрямо времевата марка на неуспешния вход, а не спрямо времето, когато сте започнали разследването.

ausearch -m AVC,USER_AVC -ts recent

Празният резултат не е доказателство за невинност. Той означава или че одитът не събира, или че прозорецът ви е пропуснал опита, и двете възможности трябва да бъдат изключени, преди да изключите политиката.

Ръководството за отстраняване на проблеми със SELinux на Red Hat поставя проверките на етикетите и конфигурацията преди генерирането на правила за разрешаване, което е правилният ред и за този проблем. Неправилно етикетиран двоичен файл и пропуск в политиката дават подобни откази, но се нуждаят от различни поправки. Генерирането на правило за разрешаване за грешка в етикета скрива дефекта и оставя следващата актуализация на пакета да го върне. Потвърдете етикета на инсталираната помощна програма, преди да пишете каквато и да е политика.

Докажете промяната с един приет и един отхвърлен вход

Променете само границата, която демонстрирахте, след което тествайте и двата изхода. Акаунт, който трябва да се удостовери, трябва да успее, а акаунт с грешна парола трябва все още да се провали. Промяна, която прави всеки опит успешен, е премахнала удостоверяването, вместо да го поправи.

Направете реален опит за връзка и прочетете журнала веднага след това. Редът, който доказва поправката, е записът pam_unix(openvpn:auth) за този опит: той трябва да показва успешно удостоверяване и нито един запис AVC не трябва да е в същата секунда.

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

Работещият тунел се нуждае и от повторно свързване, защото промените в sandbox чупят второто свързване по-често от първото. Проверете установения сокет след повторното свързване и потвърдете, че същият unit все още го обслужва.