[MEGOLDVA] SELinux + check_nrpe + curl

 ( gdavid | 2018. október 18., csütörtök - 8:12 )

Sziasztok

OS: centos 7
check_nrpe-vel szeretnék lekérdezni egy http://localhost:1234/health porton ülő szolgáltatás xml-jét feldolgozni egy saját bash scripttel.
A script eredménye a szokásos OK, Warning + message, Critical + message lenne.

nrpe userrel futtatva a script hibátlanul lefut (a curl is)
check_nrpe -n keresztül futtatva, bár a script lefut, azonban a scriptben ülő curl mindig 7-es (cannot connect) értékkel jön vissza.
Amennyiben setenforce 0 beállítás megtörténik, a check_nrpe simán visszaadja a helyes értéket.

Ami szépít, hogy az audit.log nem tartalmaz semmilyen denied -ot, akkor sem ha semodule -DB lefutott.

Sajnos a permissive és disabled módok nem járhatóak.
Nincs valakinek ötlete/tapasztalata ezzel kapcsolatban, hogyan lehetne rávenni a selinux-ot hogy működjön a lekérdezés?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Permissive modban logolnia kellene, fel van teve minden ami szukseges hozza, pl. setroubleshootd? Nezd meg az selinux boolean-okat is, lehet eleg csak azokon allitani.

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Én anno azt mondtam, hogy igen, jó és kell az selinux, de az ilyen faszságok miatt meguntam, és mindenhol kikapcsoltam.
Én is tömérdeket szívtam ilyen és hasonló dolgokkal... Nem logol semmit, pedig nem megy. Vagy ha én váltok nrpe userre, és tolok egy commandot megy, de ugyanez serviceként már nem. Tömérdek esetben volt, hogy gyártottam selinux szabályokat, ami jó volt egy ideig.... Majd egyszer csak egy service restart vagy reload (pl. logrorate, vagy hasonló), vagy épp gép restart után nem ment (úgy, hogy nem volt se update, se semmi). Jah, az updatekről ne is beszéljünk... Egy-egy nagyobb frissítés után kb. lehetett újragyártani az összes szabályt. De olyan is volt, hogy megkreált selinux policy átmásolva 6 gépen ment, egyen nem, az istennek se.
Szóval érdemben hozzászólni nem tudok, csak átérzem a problémádat, és leírtam, hogy nekem is az lett a vége, hogy mindenhol off.
--
"Sose a gép a hülye."

"De olyan is volt, hogy megkreált selinux policy átmásolva 6 gépen ment, egyen nem, az istennek se."

Ez ismeros :)

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

"mindenhol kikapcsoltam." - igen, ez az egyszerűbb, megtanulni, megismerni picit nehezebb...

"Nem logol semmit, pedig nem megy." - Enforced mód. Tessen permissive-ben járatni, és akkor látod, mit és miért kaszált volna el.

"megkreált selinux policy átmásolva 6 gépen ment, egyen nem, az istennek se" - Saját egyedi policy-t helyben csinálunk, az a biztos. Meg persze érdemes azt is megnézni, hogy a fájlok cimkézése is jó-e, mert az is gondot szokott okozni, hogy becsomagol/átmásol/kicsomagol során a selinuxos cimkéket nem viszi a fájl magával...

"Sose a gép a hülye." - Egyetértek, nagyon sokszor az üzemeltető. :-P

Amit fél vagy 1 év alatt nem sikerült meg- és kiismerni (nem tudom már mennyi ideig küzdöttem vele), azzal inkább nem akartam több időt elcseszni... Így is órák mentek el azzal nem egyszer, hogy mi romlott el, amikor nem megy a levél, nem indul a service, permission denied a fájlra vagy könyvtárra, pedig mennie kéne, stb... Aztán mire szétdebuggoltam, újraírtam a konfigot, és mindent elkövettem már vele, rájöttem, hogy ja, semmi, csak selinux most épp úgy gondolta, hogy akkor innentől nem engedni, ami addig ment. Egyébként a hivatalos doksikon kívül kb. nulla dolgot lehet selinux-szal kapcsolatban találni segítségként vagy támpontként, mert a legtöbb fórumba és levlistán még ha találsz is a tiedhez hasonló problémát, az a javaslat és az a vége a dolognak, hogy kikapcsoltam, jó lett. Egy tetszőleges howto pedig kivétel nélkül azzal indít, hogy kapcsold ki az selinuxot. Nem véletlenül. Nem akar vele senki küzdeni, mert nem ad annyi pluszt, és fapadosak hozzá a tool-ok, hiába lenne jó cucc.

Permissive-be volt mindig, és sokszor k*rva betűt nem írt a tiltásról.

Aha, az aztán az "enterprise solution", hogy minden gépen kreálgasd a policy-det. Véletlenül se lehessen másolni, vagy csomagból felhajítani.

Vagy a program/tool...
--
"Sose a gép a hülye."

"nem megy a levél, nem indul a service" - egy rakat RHEL/CentOS volt/van a kezem alatt, de ilyet permissive módnál nem tapasztalatam (nomrális, repóból felrakott cuccoknál enforcedben sem igazán, talán az egyik imapd köhögött, de az is az adott user nem standard helyen lévő home-ja miatt, de ott egy a cimkézés rendberakta a dolgot), legfeljebb annyit, hogy az auditd szépen tolta a logba, hogy mi az, amit (a sz@rul összelapátolt alkalmazásnál, vagy épp elkeffintett labellel bíró fájlok miatt) egyébként elkaszált volna az enforced mód.
Ha meg valami nem megy, ami addig ment, az 10-ből 8 alkalommal a fájlok cimkézésén vagy épp egy sebool beállításán múlik, de az audit2why illetve atit2allow szépen kihozza. Ja, persze, ezeket az eszközöket kell ismerni, illetve a hasnzálatukat el kell sajátítani, ami a selinuxszal való ismerkedés egyik alapja.

A policy-t azért célszerű helyben generálni, mert célszerű, ha ott figyel az adott policy modul forrása is, az amiből az aktuálisat generáltad - ugyanis ha véletlenül van már fent egy azonos nevűből 1.2 verzió, és te felmásolsz egy 1.1-est, az hiába tartalmaz többet, nem az fog érvényre jutni. Csomagból fel lehet pattintani, de azt is célszerű úgy megoldani, hogy a "forrást" másolod fel, és helyben csinálsz belőle betölthető bináris modult, és utána azt töltöd be.

Mindig az alapján csináltam a szabályokat audit2allow-val, amit logolt permissive módban, aztán mikor kész lett, betöltöttem, és visszatettem enforced-ra, mégis előfordult nem egy esetben, hogy utána sem ment. Aztán vissza permissive-re, próba újra, és jó esetben logolt olyat, amit az előző körben nem. Aztán szabály bővítés, betöltés, vissza enforced, próba, és reménykedj hogy megy. Ha nem, akkor újra... És 2-3-4-5 akárhány ilyen kör után volt hogy eljutottam oda, hogy permissive nem logolt semmit, enforced-ba meg mégse ment.

Igen tudom a verziózást, csináltam, és az említett esetet, amikor is "többnyire" ment, de előfordult hogy 1-2 helyen nem, akkor a te és pp fájlokkal is próbáltam.
--
"Sose a gép a hülye."

Mondanál példát arra, ami nem ment permissive módban, és nem volt a logban semmi? Mert ilyen esettel még nem találkoztam.
Az audit2allow az jó dolog, de az audit2why kiementét is érdemes előtte átnézni, mert az részletesebben előadja, hogy mi lenne problémás.
A több körös hangolás azmindenképp kell, ha az alkalmazáshoz nincs teljeskörű funkcionalitásra vonatkozó tesztsorozatod - nekem vmi. Oracle vacak hosszú hetekig ment permissive módban, mire a fájlcimkézést és az egyéb rule-okat korrekten sikerült összerakni, de azóta -remélhetőleg- köszöni szépen, jól van, működik, és a selinux is enforced-ben van a prod szerveren.
Ha itt-ott nem megy valami, akkor én első körben a selinuxos változókra meg a fájlok cimkézésére gondolnék - egy relabel megdöbbentő dolgokra képes, vagy akár az adott app által hasnzált fájloknak a cimkézését rendberakva id megdöbbentő javulásra lehet számítani. És a cimkézés, ahogy korábban írtam, a selinux label el tud mászni rosszul kivitelezett fájlmásolás/mozgatás során is.

Nem tudok konkrétumokat, már nem emlékszek, legalább 4-5 éve volt. Az nrpe mindig szívás volt, és a levelezéssel is volt gond többször, több gépen egy közönséges mezei hajnali logrotate-ot követő postfix vagy amavis reload után, hogy connection failed, permission denied vagy hasonlók egyszer csak, míg addig ment, és semmi egyéb nem történt.
--
"Sose a gép a hülye."

Bingo - az előző hsz.-odhoz írtam, hogy nekem a logrotate környéke a gyanús, azzal, hogy gyaníthatóan a logokat tartalmazó könyvtár selinix contect-je rossz ilyenkor.

Nem tudom mit bongózól, a legelső hozzászólásomban írtam, hogy az egyik "stabil" selinux problémaforrás a logrotate volt. :)
--
"Sose a gép a hülye."

Ott a stabil problémaforrás a könyvtár/fájl kontext hibás beállítása volt, csak ugye ehhez is ismerni kéne a selinuxot.

De pont erről beszélek, hogy nem stabil problémaforrás volt, mert nem az első logrotate-nél dobta el, hanem több nap, hetek, vagy akár hónapok után, miközben a servicekre mindig daily rotate van.
--
"Sose a gép a hülye."

Ilyet gyakran látni, amikor az R=1 user "nem csinált semmit, nem módosított semmit", és mégsem működik. Aztán csak kiderül, hogy mégiscsak módosult valami, mégiscsak csinált valamit az adott, immáron nem működő dologgal...
Tudod az az érdekes, hogy a RHEL/CentOS vonalat selinoxostól-mindenestől nagyon sokan hasnzálják, és ha ennek csak a harmada-negyede az, aki "rendesen" hasnzálja a selinuxot, és az általad leírt "mágikus problémák" normális üzem során előjönnének, akkor tele lennének ilyenekkel a rhel/centos témájú oldalak. De meglepő módon nem ez a helyzet.

Nagyon kíváncsi lennék, hogy a telepített bázis hány százalékán van enforced-ban az selinux. Szerintem minimális.
--
"Sose a gép a hülye."

Elég sok helyen, de ott értenek hozzá/haljandóak megismerni, mire való, hogyan működik, hogyan kell használni. (Ha jól csinálod, akkor production: enforced, Q/A: enforced, test/dev: permissive). Nekem nem egy olyan alkalmazáshoz volt szerencsém, ahol az app telepítési leírása "selinuxot kapcsold ki" utasítással indított - ha a rg. bután követi a leírást, akkor kikapcsolja, ha meg ésszel él, akkor a fenti felosztásban bekapcsolva hagyja, és a szükséges beállításokat összerakja magának az adott alkalmazáshoz. Igen, munka van vele, meg tudást/ismeretet kell felszívni hozzá, de a munkánk ezzel jár - az új dolgokat illendő követni.

Nagyon optimista vagy. :) Nekem ha tippelnem kéne, úgy 10 és 20% közé tenném valahova az enforce-olt selinux-ot az összes jelenleg támogatott és telepített redhat/centos/fedora rendszerre tekintve.
Próbálom követni az új dolgokat, viszont nem minden jó, ami új - szerintem ez sem a legjobb, pontosabban a működése és kidolgozása, ezért is hanyagoltam. Ha már új dolgok, nézz utána a konténer technológiáknak, mert akár tetszik, akár nem, erre megy minden, és nem csak akkor, ha "devops" vagy, amit egyébként én is rühellek.
--
"Sose a gép a hülye."

ha "devops" vagy, amit egyébként én is rühellek.

a devops-okat ruhelled, vagy hogy erre megy minden?

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Ezt az egész mesterségesen kreált szót és szakmát.
--
"Sose a gép a hülye."

Aztán mire szétdebuggoltam, újraírtam a konfigot, és mindent elkövettem már vele,

na de akkor miert a centos vonalat erolteted? :-) Annyi linux disztro van meg a vilagon...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Mert a debian vonal pár tulajdonságától meg frászt kapok...
Plusz mindig is rpm-es disztrókat használtam, régebben suse/opensuse volt.
--
"Sose a gép a hülye."

Ehhez csak annyi kiegeszitesem hadd legyen, hogy egyreszt a forumos infokal kapcsolatban igazad van, masreszt - es nem allitom, hogy ez az egy udvozito ut van, de ha egyebkent tenyleg erdekel a SELinux berhelese - van egy-ket nagyon jo konyv a temaban, ami segit eligazodni a napi ugyes-bajos dolgokban.

Köszi, már nem. Elég volt az az 1-1,5 évnyi masszív bizonytalansági faktor, amíg én magam is próbáltam erőltetni, miután megjött a centos 7 és elkezdtük használni. Már pár éve is az volt, hogy kb minden funkciónak csináljunk egy külön virtuális gépet. Ez ma már teljesen általános, sőt most már egyre inkább az van, hogy minden servicenek csináljunk egy külön konténert, és azt csinál benne amit akar, fusson rootként, írja a fájljait oda, ahova akarja, szarni bele, nem számít, mert egy kis homokozója van, és az egész szeparáció sokkal magasabb szinten van. Az selinux, apparmor és hasonló dolgok értelmüket vesztik itt. A virtuális gépes történetnél mondjuk egy webszervernél egy gépen volt db, php, webszerver; vagy egy mailnél mondjuk mta, spamfilter, víruskereső, imap/pop3; itt azért még lett volna értelme az selinuxnak. De eljutottam oda, hogy nem éri meg a plusz munkát.
--
"Sose a gép a hülye."

"írja a fájljait oda, ahova akarja, szarni bele, nem számít, mert egy kis homokozója van" - egészen addig, amíg nem babrál másadatokkal, csak a saját homokládájában bohóckodik, nem kritikus/érzékeny adatokkal. Abban a pillanatban, amikor bármilyen olyan adattal dolgozik, aminek a biztonsága (bizalmasság, sértetlenség, rendelkezésre állás) fontos, máris nem mindegy, hogy milyen foskupac az alkalmazás, meg mennyire dilettáns ezen a téren az üzemeltetés.

"nem éri meg a plusz munkát" - szerinted. Nem véletlenül van az ott és úgy, és bizony meg kell tanulni hasnzálni, ahogy anno a lokális tűzfalat is alapból "accept/accept"-re állították azok,a kik nem tudták megtanulni a használatát, mondván, hogy "msáhol van megoldva"... Csak ugye ez azt jelenti, hogy annyi DMZ-t vár el, ahány szervere a nagyvilág felől elérhető, mert zónán belül lokális tűzfal nélkül egymástól nem védi a gépeit, miközben azért minimum illene.

A selinux is ilyen dolog: ha van, akkor meg kell vele ismerkedni, vagy ha másfél év kevés volt rá, akkor - már bocs - de érdemes elgondolkodni egy kapa beszerzésén, és elmenni kapálni :-D (nem gondotlam komolyan, bár ha én kérdeznélek egy interjún, és azt mondanád, hogy selinuxot kikapcsoltan szereted, akkor rövid távon elköszönnénk egymástól...) Marhára nem űrtechnológia a selinux, nagyon perverz alkalmazások is szórabírhatók megfelelő tudással, a normális, repóból érkező alkalmazások esetében gyakorlatilag nincs vele gond, ha meg van,a kkor az auditd alapbeállításban szépen naplózza a permissive mód esetén, hogy mi lenne a gond - igaz, nem az rsyslog-on keresztül, hanem saját maga :-P

A konténernek pont az a lényege, hogy nincs más adat. Van a service, hozzá ami kell so vagy config, meg azok az adatok, amikkel dolgozik amúgy is. Futhat akár 1-es pidként, rootként is ha kell, mert nincs semmi más abban a konténerben. Ahhoz, hogy onnan kitörj és más adatokhoz hozzáférj, sokkal magasabb szintű kernel hibákat kell találni és alkalmazni, ekkor pedig már jó eséllyel az selinux se fogná meg.

Nekem jelenleg nincs időm arra, hogy mondjuk 2-3 óra alatt összerakok egy szervert, de még utána 8-10 órát tutujgassam az selinuxot, mire talán minden szabályt összetákolok, hogy menjen, majd ezt követően pár nap, hét, esetleg hónap múlva hajnal 2kor mégis úgy gondolja, hogy valami változott, és innentől nem megy tovább, és reggel azt látom, 6 órája nem megy a webszerver, vagy hogy X db mail ott van a queue-ban, mert nem tudott kimenni, és akkor essek neki újra 4-6-8 órát szabályokat tákolni/frissíteni.
--
"Sose a gép a hülye."

" még utána 8-10 órát tutujgassam az selinuxot" Ha ez így van, akkor az előző 2-3 órában csinálsz ordas nagy hibákat, mert normálisan összerakott szerveren nincs sok dolgod selinux ügyben.
Az, hogy az alkalmazás a saját adatait a konténerben tárolja, az elég érdekes, de mindegy - attól, hogy dolgozik velük, nem biztos, hogy buli, ha a konténerben elérhető app lukain keresztül lezúzható/átírható/elérhetetlenné tehető az adat.

"hajnal 2kor mégis úgy gondolja, hogy valami változott" - nem úgy gondolja, hanem tényleg változott - nem frissítés, mert azt production rendszerben nem automatice csináljuk (bár frissítés nem igazán töt el nekem selinuxos dolgokat, ami meg igen, az max. fél óra volt, dokumentálással együtt) - mondjuk pont webszerveren illendő lenne utánajárni, hogy mi, és miért hasal el selinuxon.
A hajnali kettő az saccperkábé logrotate, és az, hogy nem indul, az lehet pl. a logterület átpakolása olyan helyre, ahol a dir/file context nincs megfelelően beállítva (a semanage fcontext valóban randa, de ez is része annak, hogy megtanulni használni a selinuxot - minden esetre nem órák kérdése erre rájönni, ha az alapok megvannak).

A levél nem megy ki, az dettó logolás/context gyanús, meg esetleg sebool probléma, permissive mód és auditd ebben is segítség - megint csak nem hiszem, hogy órákon keresztül kellene egy ilyen problémára vadászni.
Ja, és production rendszer ez is, ergo ha valami változik, annak oka van, és az ok, a következményekből kiindulva simán megtalálható és megoldható.

"az előző 2-3 órában csinálsz ordas nagy hibákat"
Ha az ordas nagy hiba, hogy nem csak az official tárolókból vannak appok telepítve, hanem van pár más külső, pl. epel... Vagy az, hogy valaminek nem a default locationt adom adattárolásra, hanem valami mást... Vagy úgy egyáltalán bármiben eltérek a defaulttól... Akkor igen. Egyébként nem gondolom.

Nem azt mondtam, hogy az app az adatokat a konténeren belül tárolja, hiszen az egy múló, változó dolog. Hanem azt, hogy a konténerből elérhető az adat.

A hajnal 2-es példa csak egy volt, előfordult délelőtt 10kor is, vagy mondjuk azután, hogy átírtam egy egyébként selinux szabály szempontjából tök lényegtelen paramétert (mondjuk postfix sender_restriction-be beírtam valamit), majd nyomtam egy postfix reloadot, és ezután már a postfix nem tudta az amavisnak a levelet átadni. Nem volt se frissítés, se reboot, se semmi egyéb módosítás. Mindegy, rághatjuk még a témát, a lényeg, hogy számomra az selinux rengeteg plusz munkaórát, szívást, és az ehhez hasonlóak következtében egy masszív bizonytalansági faktort tett az amúgy stabilnak mondható rendszerekbe, mint írtam olyan is volt, hogy 10 gépen meg kellett csinálni valamit, 9-en ment (vagy működött a korábban létrehozott policy), 1-en meg nem.
--
"Sose a gép a hülye."

"valaminek nem a default locationt adom adattárolásra, hanem valami mást" - aminek a contextjét nem húzod helyre, ahogy azt kéne, máris tökönszúrtad magad selinuxilag.

"a konténerből elérhető az adat" - azaz ha a konténerben lévő alkalmazást rá lehet venni, hogy disznóságot csináljon, akkor disznóságot fog csinálni az adatokkal ugyanúgy, mintha nem konténerben futna az app. NEM az alkalmazást futtató OS-t védjük elsődlegesen az alkalmazástól, hanem a kezelt adatokat.

"selinux rengeteg plusz munkaórát, szívást, és az ehhez hasonlóak következtében egy masszív bizonytalansági faktort tett az amúgy stabilnak mondható rendszerekbe" amíg nem ismered, addig valóban jelenthet problémát, de a "szarnemmegykikapcsolom" az nagyjából olyan, mint amikor valaki (megtörtént eset...) sorban kommentezi ki a programozás feladatból azokat a sorokat/részeket, amire a fordítás hibát ad, egészen addig, amíg lefordul a motyó. Fut is, csinál is valamit, de...

akkor disznóságot fog csinálni az adatokkal ugyanúgy, mintha nem konténerben futna az app

+1. Btw. fentebb azert besirtam azon az allitason, hogy hadd fusson az app a kontenerben root-kent, barmikent. Nesze neked least privilege elve...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Nem azt írtam, hogy feltétlen és by default... De mivel a konténerbe csak ő van, és csak ahhoz a külső erőforráshoz vagy adathoz fér hozzá, amit én megadtam neki, így majdhogynem totálisan mindegy. És egyébként a kontérben lévő uid 0 nem egyenlő a futtató környezet vagy host rendszer uid 0-jával természetesen.
--
"Sose a gép a hülye."

Most vagy tényleg nem érted, vagy direkt kötekedsz.
"aminek a contextjét nem húzod helyre, ahogy azt kéne, máris tökönszúrtad magad selinuxilag."
Sokadjára leírom. Valami MEGY, érted MEGY, majd volt hogy egyszer csak nem ment. És ekkor megnéztem a szabályt, megnéztem a kontextet, az audit logot, és minden egyebet, és minden úgy volt, ahogy hagytam. Mégse ment.

"NEM az alkalmazást futtató OS-t védjük elsődlegesen az alkalmazástól, hanem a kezelt adatokat."
Mesélj már erről nekem, mert nem értem. Szóval egyszerűsítsük le a dolgot, egy service vagy csak olvas egy adatot, vagy írja is. Ha csak olvassa, akkor eleve olyan hozzáférést adsz neki, amivel csak olvasni tudja. RO csatolás, csak SELECT-re engedélyezett mysql user, fájlrendszer szinten csak r, esetleg x jog, stb... Ha írja is, akkor ahhoz hogy normálisan működjön, ugyanúgy meg kell adni selinux oldalról is az írási jogosultságot, különben nem fog működni. Akkor hogyan is jelent plusz védelmet az selinux a "disznóságot" csináló app ellen? Mert szerintem sehogy. De én kezdek belefáradni ebbe az írásba, úgyhogy inkább itt befejeztem.
--
"Sose a gép a hülye."

mas. Latom az oldalatokon, hogy van egy 25 millios felelossegbiztositasotok. Ez mennyibe kerul es mit kaptok erte?

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Azt inkább privátban. :)
--
"Sose a gép a hülye."

tanulságul:
semodule -DB #rebuildeli, és kiszedi a deauth -ot (ettol nem logol)

yum install audit (ez is kellett a korrekt logolashoz, ausearch-hoz)

- ausearch innentől már látta a logokat meg a denied-eket.
- rákerestem az audit-ban a check_nrpe -re megjelenő sorokra, betettem csak ezeket egy fájlba,
- audit2allow -w -i # ahova fenti sorokat tettem
- setsebool -P nis_enabled 1 # ezt mondta... ééés működik. (A -P fixálja.)

OFF:
"szolgáltatás xml-jét feldolgozni egy saját bash scripttel" - xml-t kurkászni a legutolsó, amit előszednék, az a bash. Bár a Python nem a szívem csücske, de erre pont, hogy Python-t ragadnék :-P

Hi!

Most kezdtem SELinux beállításaival foglalkozni pár hete. Két szerveren sikerült is beállítani. Tapasztalatom haladó linuxosként, ( profi még nem vagyok, néha még beszakad a jég :D) a szolgáltatások, rendszer működést kell megtanulni először és persze a selinux működését is. Ez sok idő. Ezt nem akarják sokan.
Találtam jó anyagokat:
https://linuxtechlab.com/beginners-guide-to-selinux/
https://centoshelp.org/security/selinux-common-commands-troubleshooting/
https://opensource.com/article/18/7/sysadmin-guide-selinux
http://pages.mtu.edu/~xinlwang/itseed/labs/SELinux_Policy.pdf
https://www.certdepot.net/rhel7-use-selinux-port-labelling/
https://www.systutorials.com/docs/linux/man/8-bind_selinux/

Ezek sokat segítettek.
Én is lusta vagyok :D, de kellett csinálnom egy tesztgépet.