Чаму перанос сертыфіката VPN ламае яго метку SELinux

Сертыфікаты могуць ляжаць у правільным каталозе з чытэльным рэжымам і ўласнікам root, і служба ўсё роўна можа паведаміць, што не можа адкрыць файл. У сістэме SELinux такая спалучэнне паказвае на адзін канкрэтны механізм, а не на правы. Метка пераехала разам з файлам, бо перайменаванне не стварае новы аб’ект. Інод захаваў кантэкст бяспекі, які меў на старым шляху, а палітыка новага шляху так і не атрымала магчымасці прызначыць свой.

Што перайменаванне насамрэч робіць з меткай

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

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

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

Чытайце бягучую метку супраць чаканай

Тры каманды толькі для чытання адказваюць на пытанне, нічога не змяняючы. Першая паказвае, што файл мае зараз, другая паведамляе, што палітыка чакае для менавіта гэтага шляху, а трэцяя пералічвае кожны файл у каталозе, чыя метка адрозніваецца.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

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

Аднавіце адлюстраванне замест вынаходкі выключэння

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

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

Чаму chcon не вырашае праблему

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

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

Калі метка правільная, а доступ усё роўна не працуе

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

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

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