Аўтэнтыфікацыя PAM працуе ўручную, але не працуе як служба OpenVPN

Аўтэнтыфікацыя праз PAM можа прайсці, калі вы запускаеце кліент уручную, і скончыцца няўдачай з AUTH_FAILED, як толькі systemd запусціць той жа профіль. Пароль паміж гэтымі запускамі не змяняецца; змяняецца набор абмежаванняў вакол працэсу, які задае PAM пытанне. PAM адказвае праз дапаможную праграму, здольнасць якой змяняць уласныя ўліковыя даныя — гэта менавіта тое, што выдаляе ўзмоцнены unit. Знайдзіце гэтую праграму і мяжу, якая ёй патрэбна, перш чым кранаць спіс магчымасцей.

unix_chkpwd — гэта бінарны файл, які адказвае на пытанне PAM

Пры лакальнай аўтэнтыфікацыі па паролі pam_unix рэдка чытае сам файл хэшаў. Ён выконвае 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

Пусты вынік не з’яўляецца доказам невінаватасці. Ён азначае або што аўдыт не збірае, або што вашае акно прапусціла спробу, і абедзве магчымасці трэба выключыць, перш чым выключыць палітыку.

Кіраўніцтва па выпраўленні праблем SELinux ад Red Hat ставіць праверкі пазнак і канфігурацыі перад стварэннем правілаў дазволу, і гэта правільны парадак і для гэтай праблемы. Няправільна пазначаны бінарны файл і прабел у палітыцы даюць падобныя адмовы, але патрабуюць розных выпраўленняў. Стварэнне правіла дазволу для памылкі пазнакі хавае дэфект і пакідае наступнае абнаўленне пакета зноў увесці яго. Пацвердзіце пазнаку ўсталяванай праграмы, перш чым пісаць любую палітыку.

Давядзіце змену адным прынятым і адным адхіленым уваходам

Змяніце толькі тую мяжу, якую вы прадэманстравалі, затым праверце абодва вынікі. Уліковы запіс, які павінен прайсці аўтэнтыфікацыю, мусіць атрымаць поспех, а ўліковы запіс з няправільным паролем — па-ранейшаму пацярпець няўдачу. Змена, якая робіць паспяховай кожную спробу, выдаліла аўтэнтыфікацыю замест таго, каб адрамантаваць яе.

Зрабіце рэальную спробу злучэння і адразу прачытайце журнал. Радок, які даказвае выпраўленне, — гэта запіс pam_unix(openvpn:auth) для гэтай спробы: у ім павінна быць пазначана паспяховая аўтэнтыфікацыя, і ні адзін запіс AVC не павінен прыпадаць на тую ж секунду.

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

Працуючы тунель таксама патрабуе перападключэння, бо змены пясочніцы часцей ламаюць другое злучэнне, чым першае. Праверце ўсталяваны сокет пасля перападключэння і пераканайцеся, што той жа unit усё яшчэ абслугоўвае яго.