Збой 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, але толькі калі набор спадчыны выкананага файла гэта дазваляе, таму біт там сам па сабе нічога не дае.

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

Дадавайце правіла магчымасці толькі калі так кажа аўдыцыйны след

Запісы ядра і аўдыту называюць слой, які адмовіў. Шукайце адмову, якая нясе аперацыю capable і імя sys_chroot, разам з профілем, што яе спарадзіў. Калі такі запіс ёсць, працэс ужо валодаў магчымасцю, а AppArmor адмовіў, і мэтанакіраванае змяненне — гэта правіла магчымасці ўнутры сапраўднага профілю:

capability sys_chroot,

Трымайце яго фрагментам у тым профілі, які сапраўды далучаны, і звярайце ключавое слова з даведкай па профілях apparmor.d, а не капіюйце правіла з непатрэбнага падручніка. Калі пакласці яго ў агульны ўключаны файл, яно даецца кожнай абмежаванай праграме, што цягне гэты файл, а пераключэнне профіляў у рэжым скаргаў хавае наступную адмову замест таго, каб вырашыць гэтую. Правіла профілю здымае адмову палітыкі; яно не стварае прывілею, таму працэс, у якога ніколі не было CAP_SYS_CHROOT у эфектыўным наборы, усё роўна атрымае збой нават з гэтым правілам.

Калі аўдыцыйны запіс зусім не паказвае адмовы AppArmor, спыніце правіць профіль. Вы маеце справу з праблемай уліковых даных, і пакінутая праца — у файле модуля або бацькоўскім працэсе, а не ў мове палітыкі.

Менеджар службаў трымае ўласны стол

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

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

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

Пасля зняцця адмовы праверце сам астрог

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

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

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