Fórumok
Sziasztok
adott egy centos8, amit icinga2 monitoroz,
ezt a parancsot futtatná:
sudo -u barman /usr/bin/barman check prod-primary --nagios
amikor kipróbálom a célgépen icinga user alol:
BARMAN OK - Ready to serve the Espresso backup for prod-primary|prod-primary=156353053B prod-primary_wals=905969664B
minden szuperzöld
ugyanakkor mikor ezt az icinga2 program végzi el, hibaüzenet fogad (tehát nincs terminál).
ha a selinux-ot permissive módba teszem, megint csak az elvárt eredményt adja vissza a check.
a messagesben megjegyzi, hogy futtasam
ausearch -c 'barman' --raw | audit2allow -M my-barman; semodule -X 300 -i my-barman.pp
de hiába futtatom akárhányszor le változás nem keletkezik, minden változatlan.
Hozzászólások
Mielőtt futtatod a jelzett parancsot, állítsd permissive-re a Selinuxot, majd futtatás után vissza enforced-ra.
A 'disabled' mód lenne a praktikusabb.
Nem, az a kényelmes megoldás. A praktikus az, ha beállítja megfelelően.
MLf, már bocsánat... (Igen, az "M" az a "mega" prefix...) Meg kell nézni és értelmezni a selinux permissive módban dobott üzenetet (audit2why), és utána fájl/könyvtár kontextust illetve selinux policy-t helyrehúzni.
A legvalószínűbb, hogy a chí (vagy kí) nem a feng-sui szabályai szerint áramlott a rendszergazdában, ezért nem sikerült a művelet.
Szerintem meg az, hogy sajnos lövése sincs (azokhoz hasonlóan, akik a kikapcsolását tartják üdvözítő megoldásnak) a selinux működéséhez, használatához, beállításaihoz. Igen, ez túlmutat a 12 bitnyi hozzáférési maszkon meg a fájlrendszerre húzott ACL-eken - de ilyen az élet - meg a domain / label alapon működő security...
Ez igaz, eddig még valahányszor rákérdeztem, hogy pontosan mi az a SeLinux, és pontosan mire jó, mindig az volt a válasz, hogy az egy nagyon szép és nagy komplex biztonsági rendszer, és ha googlézok szorgalmasan, talán találok olyan problémát, amit megold a SeLinux. (Ahhoz nem kell a google, hogy olyan problémát találjak, amit okoz a SeLinux.)
Egykoron vala a diszkrecionális hozzáférésvezérlés (fájlokra: user/group/others, rwx), ami sok esetben elég, de nincs kikényszerítve. "Példaként vegyük azt az esetet[15], amikor András elkészít egy titkos dokumentumot. A dokumentum annyira titkos, hogy csak Béla láthatja, de Cecília, a titkárnő már nem. András beállítja a dokumentum hozzáférési jogait úgy hogy csak Béla láthassa. De Béla nyúl, és a dokumentumról készít egy másolatot Cecília részére, hogy helyette ő végezze el a dokumentummal végzendőket. Igen ám, de Cecília tulajdonképpen a versenytárs cég felbérelt ügynöke, és huss, elküldi a dokumentumot az APEHnek. Ilyen és hasonló esetekre találták ki a kötelező hozzáférésvezérlési modelleket." ( https://mek.oszk.hu/01200/01238/index.phtml )
Mondjuk egy apache sebezhetőségen bejött disznóság alapesetben a fájlrendszerben minimum az "others" jogosultságokkal elérhető dolgokhoz hozzáfér, ha nincs selinux - hiszen a diszkrecionális modellben az a processz "others"-be tartozik, de ugyanígy simán jogosult 1024 fölötti portra ráülni... stb. Viszon mindezeket _nem_ fogja tudni, mert ez a disznóság nem csak az usert/group-ot viszi magával, hanem a selinux contextet is, amiből például csak azok a fájlok olvashatóak, amiknek a selinux cimkéje ezt explicit megengedi. Sőt fájlt írni is csak akkor tud, ha az adott könyvtár cimkéje lehetővé teszi, hogy ott fájlt hozzon létre. Ugyanígy a contextje határozza meg, hogy hálózatilag mit csinálhat és mit nem.
Másolj be egy audit2why kimenetet, azt meg tudjuk köpködni yool :-)
"ausearch -c 'barman' --raw | audit2allow -M my-barman; semodule -X 300 -i my-barman.pp" - ezzel elvileg vakon, minden vizsgálat nélkül adsz selinux-os permissiont arra, amit az bekapcsolt módban elkaszálna. Ez nagyon nem jó, még akkor sem, ha tudod mit csinál/hogyan működik a selinux - ha meg nem tudod, akkor pláne.
audit2why tudja megmondani, hogy mit és miért kaszált (volna) el a selinux, utána egy audit2allow kiementét célszerű megnézni, hogy _szerinte_ mit kell beállítani. Ezt követően el kell dönteni, hogy hogyan célszerű megoldani a problémát. Lehet, hogy selinux-os paramétert kell állítani hozzá (sesebool), lehet, hogy fájlokat/könyvtárakat kell cimkézni (semanage fcontext...), vagy lehet, hogy saját, selinux szabály(oka)t tartalmazó selinux modult kell létrehozni - és persze ennek a háromnak tetszőleges kombinációja szembe jöhet - bár leginkább az első meg a harmadik az, amivel ténylegesen találkozik az átlag rendszergazda.
Egy megjegyzés...: A CentOS8 két hét múlva EOL, szerintem érdemes lenne átgondolni, hogy hogyan tovább (Én speciel OEL8-ra léptem (inplace ment a váltás), de mindenkinek szíve joga, mit csinál...).
azért íertam centos-t mert rocky-rhel-alma egykutya (még) a centossal.
"ausearch -c 'barman' --raw | audit2allow -M my-barman; semodule -X 300 -i my-barman.pp" nem mukodik.
sealert -a /var/log/audit/audit.log szöszmötölt vagy 6 órát, mire adott 8 ugyan olyan + 3 másik ausearch.... megoldást, azonban még mindig semmi.
hétfőn kipróbálom az audit2why -t hátha valami értelmesebbet mond.
kipróbáltam egy semanage fcontext váltást is, de egyelőre nem akar működni
viszont a hibák oka csökkent, mert már "csak"
hibát kapok.
Ami nagyon nagyon furcsa számomra, hogy root -> icinga váltás után shell-ből simán megkapom a helyes és elvárt "OK ...." úgty hogy az icinga sudo -u barman -nel kérdez le.
De mikor simán az icinga2 program adja ki a sudo -u barman ... -el ugyan azt akkor hibára fut.
A megoldások mik voltak, amiket kiírt? Nem utaltak arra, hogy márpedig terminál kell neki, ami alapból tiltva van a daemon-oknak?
cat my-barman3.te
module my-barman3 1.0;
require {
type var_lib_t;
type var_log_t;
type icinga2_t;
type krb5_keytab_t;
type var_t;
type unlabeled_t;
class dir { getattr open read search };
class file { getattr ioctl lock open read write };
}
#============= icinga2_t ==============
#!!!! This avc is allowed in the current policy
allow icinga2_t krb5_keytab_t:dir search;
#!!!! This avc is allowed in the current policy
allow icinga2_t unlabeled_t:dir { getattr open read search };
#!!!! This avc is allowed in the current policy
allow icinga2_t unlabeled_t:file getattr;
allow icinga2_t unlabeled_t:file read;
#!!!! This avc is allowed in the current policy
allow icinga2_t var_lib_t:file getattr;
#!!!! This avc is allowed in the current policy
allow icinga2_t var_log_t:file open;
#!!!! This avc is allowed in the current policy
allow icinga2_t var_t:dir read;
#!!!! This avc is allowed in the current policy
#!!!! This av rule may have been overridden by an extended permission av rule
allow icinga2_t var_t:file { getattr ioctl lock open read write };
de ez sem oldja meg.
Na ilyen modult nem lett volna szabad megcsinálni és betölteni (mert most ezek a rule-ok élnek). Meg kell nézni (audit2why kimenete, illetve az auditd log-ban keresgéléssel), hogy az a cimkézetlen fájl az micsoda, és első körben a cimkézést rendbe rakni, utána újabb kört futni az audit2why, audit2allow nézegetésével.
Meg kéne nézni azt is, hogy ami fut, illetve az user, aki futtatja, annak milyen labelek vannak beállítva, mert a ki mit futtathat és mihez férhet hozzá döntés ezek alapján _is_ történik.
Még csomagból felrakott dolgoknál is szembe jöhetnek selinuxos "na erre nem gondolt a fejlesztő/csomag karbantartó dolgok - saját scriptek, saját build esetén meg pláne.
érzésem szerint minden probléma gyökere abban rejlik, hogy a DB-s csapat másként szereti futtatni a dolgaikat, mint azt a gyártó kitalálta, és spéci könyvtárba pakolják a backup,repmgr,stb fájljaikat....
Troll: mindez egyáltalán nem úgy hangzik, mintha egy túltolt fősodratú idealizmus lenne a rendszerben.
Akkor tessék a DB-csapatot tökönrúgni alaposan - nem, nem ők fingják a passzátszelet, vannak a dolgoknak default helyük, tessék a szemetükkel oda dolgozni. Ha meg nem megy, akkor adják meg, hogy milyen alapértelmezett könyvtár helyett milyen másikat használnak - utána pedig te rakd össze a semanage fcontext "sorminta" parancsokat úgy, hogy az jól is működjön...
úgy látszik kellő számossággal kellett futtatni ahhoz, hogy egyszer csak ne jelenjen meg.