Pisanie własnych polityk i ogólnie własny tuning na tym poziomie to piękny, ale i złożony proces. W ścieżce z bezpieczeństwa RHEL-a było nawet szkolenie trwające 4 dni omawiające ten temat i tylko ten temat, dlatego ciężko będzie tutaj opisać cały proces.

Na pewno przyda się uruchomienie "dodatkowego" logowania zdarzeń SELinuxa  za pomocą oprogramowania: setrouble*

Potem powtarzamy zdarzenie, które generuje DENY i uruchamiamy sealert -l <identyfikator zdarzenia> zgodnie z zaleceniem, które pojawi się w /var/log/messages - to jest już dobry start do analizy dokładnie tego, co jest nie tak.

Myślę, że jeszcze jakieś dobre sugestie będzie mógł podać mój kolega Artur Szymczak, który pewnie ze skromności zaprzeczy, ale jest na poziomie wiedzy z SELinuxa prawie jak developer SELinuxa. A jako ciekawostkę powiem, że jeden z developerów, jednej z największych dystrybucji jest w aktywnym kontakcie z Arturem w kwestii omawiania tego, jak wdrażać SELinuxa w tej dystrybucji.

Poproszę Artura, gdyby nie zauważył tego posta, by się tutaj odniósł; wszystko, co napisze w kwestii SELinuxa jest warte analizy! :) Na początek polecam jego webinar o SELinux dostępny u nas: