ProtectHome наспроти TOTP семе: зошто најавувањето на VPN не успева

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

Кој од трите неуспеси е ова?

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

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

Приказот на датотечниот систем на единицата е вообичаениот виновник кога неуспева само сервисот.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

Опција A: преместете ја тајната надвор од дома

Кога сервисот го крие /home а вие преферирате да ја задржите таа заштита, чувајте ја тајната каде што може да ја види. Модулот прифаќа патека secret= и сметка user= што ги извршува датотечните операции, што му овозможува на централно складиште да опслужува многу идентитети.

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

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Проверете три работи пред да ѝ верувате: сметката постои, работниот процес на модулот може да се префрли на неа и датотеките се нејзини со ограничувачки режими. Не користете ~ или патека со домашна променлива заедно со user=, и не ги исклучувајте проверките за сопственост на модулот за да направите патека да работи. Задржете ја фазата со лозинка и остатокот од стекот недопрени.

Опција B: оставете ја датотеката и отворете патека

Ако тајната мора да остане во домашната директорија на корисникот, единицата треба приказ што ја вклучува таа една директорија без да ги открие сите домашни директориуми на домаќинот. Drop-in може да додаде тесно ограничено bind монтирање под сендбоксиран дом.

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

Две граници лесно се пропуштаат. Патека само за читање додадена под директорија што сендбоксот ја крие не ја открива, зашто родителот едноставно го нема. И монтирањето мора да биде запишливо ако модулот треба да го ажурира состојбата, што ја воведува следната опција. Напишете го drop-in како одделна датотека наместо да ја уредувате спакуваната единица под /usr/lib, за да не ја поништи тивко надградбата на пакетот.

Опција C: задржете го сендбоксот и поправете ги записите на состојбата

Читањето на тајната е само половина од автентикацијата. Модулот може да презапише информации за временско отстапување, заштита од повторување или бројач, а датотека што ја поминува проверката за читање сепак може да не успее при запишувањето.

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

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

Проверувајте како сервисот, не како вие самите

Секоја важна проверка мора да се изврши во сендбоксот на единицата со идентитетот на единицата.

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

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