chroot не успева на OpenVPN: AppArmor правило или способност?

Демонот регистрира неуспех на chroot и профилот веќе изгледа дарежлив, па примамливото решение е да се прошири правило за патека и да се рестартира. Тоа обично не менува ништо, бидејќи chroot е контролиран од привилегија што профилот никогаш не можел да ја предаде. За да се одлучи кој слој да се допре, потребни се три евтини проверки: што на процесот му е дозволено да држи, што дозволува политиката и што отстранил стартерот пред двете да станат важни.

Две одделни порти, и само едната му припаѓа на AppArmor

chroot бара CAP_SYS_CHROOT во просторот на имиња на корисникот во кој работи процесот. Тоа е вообичаена Linux привилегија, која јадрото ја проверува пред повикот да направи нешто со патеките. Одделно, профил на AppArmor во режим на спроведување може да ја одбие способноста и кога процесот ја има, бидејќи задолжителната политика се проверува покрај акредитивите, а не наместо нив. Разликата е важна во практика: двата слоја живеат во различни датотеки и обично различни луѓе ги одржуваат.

Тие две порти не успеваат со истиот errno. Двете произведуваат EPERM и двете се појавуваат како општа жалба за дозвола во дневникот на демонот, поради што погодувањето на содржината на профилот троши толку време. Правилото за патека што сакавте да го додадете контролира пристап до датотеки откако chroot ќе успее; тоа нема никаква врска со тоа дали операцијата воопшто е дозволена.

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

Прочитајте ја состојбата на привилегиите пред да ја уредите политиката

Започнете од процесот што работи, а не од конфигурацијата што верувате дека е активна. Датотеката за состојба открива пет маски на способности и знамето no-new-privileges, и тие одговараат на различни прашања:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff е множеството што е важно за повикот: способност присутна во CapBnd, но отсутна во CapEff, е дозволена од таванот и не е тековно држена. CapAmb е важна кога бинарната датотека не е привилегирана во вообичаената setuid смисла, бидејќи амбиенталните способности се начинот на кој услугата задржува привилегија преку exec без датотечни способности. CapInh држи битови што можат да се наследат преку exec, но само кога наследливото множество на извршената датотека го дозволува тоа, па битот таму сам по себе не дава ништо.

Потоа потврдете кој профил е навистина закачен. Процесот може да биде ограничен со име на профил што не го очекувавте, особено кога дистрибуцијата ја испраќа својата unit датотека и профилот заедно, а читањето на /proc/PID/attr/current тоа го решава во една линија. Споредувањето на вашата уредена датотека со профилот што го пријавува јадрото е разликата меѓу поправање на причината и уредување на датотека што никој не ја вчитува.

Додајте го правилото за способност само кога трагата од ревизија го вели тоа

Записите на јадрото и ревизијата го именуваат слојот што одбил. Барајте одбивање што ја носи операцијата capable и името sys_chroot, заедно со профилот што го произвел. Ако тој запис постои, процесот веќе ја имал способноста и AppArmor го одбил, а целната промена е правило за способност внатре во вистинскиот профил:

capability sys_chroot,

Чувајте го како фрагмент во профилот што навистина е закачен, и проверете го клучниот збор спроти референцата за apparmor.d профили наместо да копирате правило од несроден туторијал. Вметнувањето во заеднички include го дава на секоја ограничена програма што ја влече таа датотека, а префрлањето на профилот во complain режим го крие следното одбивање наместо да го реши ова. Правилото во профилот отстранува одбивање на политика; тоа не создава привилегија, па процес што никогаш немал CAP_SYS_CHROOT во ефективното множество ќе не успее и со правилото.

Ако записот од ревизија воопшто не покажува одбивање на AppArmor, престанете да го уредувате профилот. Гледате проблем со акредитиви, а преостанатата работа е во unit датотеката или во родителскиот процес, не во јазикот на политиката.

Менаџерот на услуги држи свој таван

systemd поставува ограничувачко множество на способности за секоја услуга, и по стандард тоа множество е тесно. Сè што е таму исклучено е недостапно за процесот, што и да каже профилот, поради што зацврстените unit-и можат да не успеат во операција што работела кога демонот бил стартуван рачно. Релевантните директиви лесно се читаат во unit-от и лесно се превидуваат кога апликацијата пријавува грешка. Drop-in датотеките што ги испорачува дистрибуциски пакет се вообичаен извор на таван што никој не се сеќава дека го конфигурирал.

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

И редоследот е важен. Прво сменете го таванот на unit-от, потврдете дека CapEff сега го содржи битот, и само тогаш одлучете дали AppArmor сè уште одбива. Правењето на двете промени одеднаш ве остава повторно да погодувате ако неуспехот продолжи.

Откако одбивањето ќе исчезне, проверете го самиот затвор

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

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

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