Nagios + Nrpe + SELinux

5.10.2022 23:42 | Přečteno: 3386× | linux | poslední úprava: 5.10.2022 23:46

Jak detekovat problémy s SELinux a jak je řešit?

BFU řešení?

Většinou bývá na začátku různých návodů deaktivace SELinuxu. Nebo v případě, že něco nejde, tak se jde a deaktivuje SELinux a dál už se to neřeší. Takže takto ne. Teď si ukážeme, jak problémy dohledat a řešit. Tento zápisek vznikl jako pokračování zápisku: Střípky z IT - (9) : Nagios : Uhádnete, kde byl problém?

Ve zmíněném zápisku to může chvilku vypadat beznadějně, ale ve skutečnosti je to celkem jednoduché.

Diagnostika

Budeme si vše ukazovat na AlmaLinux 8.x. Když máme nějaký problém s oprávněními, tak šup se podívat do logu. Bezpečnostní věci se logují do audit logu, tj. do "/var/log/audit/audit.log". V případě zmíněného kvízu tam uvidíme něco jako toto:

tail -n 50 /var/log/audit/audit.log |grep -i AVC
type=AVC msg=audit(1664983293.312:637187): avc:  denied  { getattr } for  pid=1461003 comm="sh" path="/usr/bin/sudo" dev="dm-2" ino=20254 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file permissive=0
type=AVC msg=audit(1664983293.312:637188): avc:  denied  { getattr } for  pid=1461003 comm="sh" path="/usr/bin/sudo" dev="dm-2" ino=20254 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:sudo_exec_t:s0 tclass=file permissive=0

Co teď? Nu, evidentně je to problém SELinuxu. Můžeme si zkusit ho dočasně vypnout a ověřit funkčnost takto:

# deaktivace SELinux (logy se budou tvořit dále, ale politiky se nebudou uplatňovat)
setenforce 0

# ověříme, že je deaktivováno
getenforce

# provedeme akci, která nám nešla

# následně znovu povolíme SELinux (restarty apod.  nejsou třeba, vše funguje hned)
setenforce 1
getenforce

nrpe-selinux

Systém není postaven hloupě, s SELinux se počítá. Proto existuje balíček "nrpe-selinux". Tento balíček by měl doplnit kompatibilitu nagios modulů s SELinux. Stačí jen nainstalovat balíček:

dnf install nrpe-selinux

Tento balíček nainstaluje SELinux politiku, takže pak v modulech uvidíme "nrpe_epel" :

emodule -l |grep nrpe
nrpe_epel

Po instalaci tohoto modulu je potřeba zapnout ještě fci na povolení volání sudo:

# povolíme
setsebool -P nagios_run_sudo on

# ověříme nastavení
getsebool -a |grep -i nagi
logging_syslogd_run_nagios_plugins --> off
nagios_run_pnp4nagios --> off
nagios_run_sudo --> on
nagios_use_nfs --> off

Problém je, že i tak nám to nebude fungovat. Důvod je ten, že tyto politiky nepočítají s moduly třetích stran. Jsou stavěny jen na moduly dodávané s ditribucí / repositářem apod. My ale chceme používat 3rd modul, který volá systemctl apod. Chybu, kterou v našem případě pak dostaneme bude:

# původní chyba (setsebool -P nagios_run_sudo off):
NRPE: Unable to read output

# aktuální chyba (setsebool -P nagios_run_sudo on)
UNKNOWN: nagiosplugin.error.CheckError: [Errno 13] Permission denied: 'systemctl'

SELinux politiky

Na práci s SELinuxem máme nějaké nástroje, které nejsou by default součástí instalace (např. audit2allow), takže doinstalujeme:

dnf install setroubleshoot

Nyní si můžeme udělat přehledný výpis chyb z logu, ze kterých pak můžeme vyrobit SELinux politiku:

# vyhledání záznamů v logu
ausearch -m AVC --start 02/04/2019 17:00:00 --end 02/04/2019 18:00:00

# konverze do čitelnějšího formátu
ausearch -m AVC --start 02/04/2019 17:00:00 --end 02/04/2019 18:00:00 | audit2allow

#============= nrpe_t ==============

#!!!! This avc is allowed in the current policy
allow nrpe_t chkpwd_exec_t:file { execute execute_no_trans map open read };
allow nrpe_t gconf_home_t:dir search;
allow nrpe_t init_t:unix_stream_socket connectto;
allow nrpe_t initrc_var_run_t:file { lock open read };
allow nrpe_t self:capability dac_read_search;

#!!!! This avc is allowed in the current policy
allow nrpe_t self:capability audit_write;

#!!!! This avc is allowed in the current policy
allow nrpe_t self:netlink_audit_socket { create nlmsg_relay };

#!!!! This avc has a dontaudit rule in the current policy
allow nrpe_t shadow_t:file { getattr open read };

#!!!! This avc is allowed in the current policy
allow nrpe_t sudo_exec_t:file { execute execute_no_trans getattr map open read };

#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
allow nrpe_t systemd_systemctl_exec_t:file map;
allow nrpe_t systemd_systemctl_exec_t:file { execute execute_no_trans open read };

Znalý člověk SELinuxu si všiml, že výše je chyba. Tou chybou je vyhledávání logů ohledně AVC. Existuje totiž ještě USER_AVC. Takže celé by to mělo být (za přesnost výpisu neručím, jsou to starší poznámky, možná neúplné, je třeba to brát jako příklad, jak postupovat):

ausearch -m AVC,USER_AVC --start 10/05/2022 17:00:00 --end 10/05/2022 18:00:00 | audit2allow

#============= nrpe_t ==============

#!!!! This avc is allowed in the current policy
allow nrpe_t chkpwd_exec_t:file { execute execute_no_trans map open read };

#!!!! This avc is allowed in the current policy
allow nrpe_t gconf_home_t:dir search;
allow nrpe_t init_t:system status;

#!!!! This avc is allowed in the current policy
allow nrpe_t init_t:unix_stream_socket connectto;

#!!!! This avc is allowed in the current policy
allow nrpe_t initrc_var_run_t:file { lock open read };

#!!!! This avc is allowed in the current policy
allow nrpe_t self:capability { audit_write dac_read_search };

#!!!! This avc is allowed in the current policy
allow nrpe_t self:netlink_audit_socket { create nlmsg_relay };

#!!!! This avc is allowed in the current policy
allow nrpe_t shadow_t:file { getattr open read };

#!!!! This avc is allowed in the current policy
allow nrpe_t sudo_exec_t:file { execute execute_no_trans getattr map open read };

#!!!! This avc is allowed in the current policy
allow nrpe_t systemd_logind_t:dbus send_msg;

#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'
allow nrpe_t systemd_systemctl_exec_t:file map;
allow nrpe_t systemd_systemctl_exec_t:file { execute execute_no_trans open read };

#!!!! This avc is allowed in the current policy
allow nrpe_t systemd_unit_file_t:service status;

#============= systemd_logind_t ==============

#!!!! This avc is allowed in the current policy
allow systemd_logind_t nrpe_t:dbus send_msg;

Vygenerujeme si policy pro SELinux a provedeme import

# vygenerování policy / modulu
ausearch -m AVC,USER_AVC --start 10/05/2022 17:00:00 --end 10/05/2022 18:00:00 | audit2allow -a -M nrpe_systemd

# výstupem jsou dva soubory:
nrpe_systemd.te # čitelný, ze kterého se vyrábí nečitelný modul
nrpe_systemd.pp # modul jako výstup z ".te" souboru

# import modulu
semodule -i nrpe_systemd.pp

# ověření, že byl naimportován
semodule -l |grep nrpe
nrpe_epel
nrpe_systemd

Po naimportování modulu začne fungovat i vzdálené volání "check_systemd" a vše šlape.

Závěr

V zápisku jsme si ukázali, jak jednoduše najít, kde je problém, jaký je postup pro jeho řešení apod. Pokud použijeme předpřipravené nástroje, není to nic složitého.

Zdar Max        

Komentáře

[X]

Muzes zavrit ten bug ;)..

[Max]

Není zřejmé, že jde o to samé. Nebo jsem něco přehlédl?
Zdar Max

[X]

ano

[X]

Piste laskave za sebe ok? Hm?

[alkoholik]

Je strasne jednoduche se podivat do logu, jestli ta hlaska zmizela.
Ja bych si tipnul ze ne, protoze jde o jiny problem.

[Ruža Becelin]

> tail -n 50 /var/log/audit/audit.log |grep -i AVC

Projde jenom pod rootem a jeste je tam zbytecna pipe, radeji tedy:

sudo grep -i AVC /var/log/audit/audit.log

Navic proc grepovat, kdyz mame audit2why?

[Max]

Tak audit2why není standardní součástí distribuce, takže proto. Grep přes pajpu dělám ze zvyku a většinou kvůli i omezení počtu řádků, proto ten "tail -n 50". Na druhou stranu, v některých případech ale dělám i rovnou grep (když něco hledám v adresáři a podadresářích).
Zdar Max

[Ruža Becelin]

Hmm, ja ho teda v Alme 8 mam:

policycoreutils-python-utils-2.9-19.el8.noarch : SELinux policy core python utilities
Repo        : baseos
Matched from:
Filename    : /usr/bin/audit2why

Coz je mimochodem uplne ten samy balik, ktery obsahuje audit2allow.

To s tim omezenim poctu radku nechapu - takhle, asi bych ev. grepoval primo ten proces, takze grep sudo /var/log/audit/audit.log, ale i tak davam prednost audit2why.

[Max]

Překouknul jsem se, myslel jsem audit2allow, který by měl být součástí setroubleshoot.
No, mám velký log, chci si parsovat jen posledních x řádků, nechci ten soubor prohledávat celý. A grep posledních 50 řádků udělám jednoduše přes tail -n 50 |grep...
Zdar Max

[Max]

Tak ne, asi je fakt součástí policycoreutils-python-utils. Každopádně nebylo nainstalováno by default.
Zdar Max

[tlamik]

Narazil jsem na podobnou chybu, resp. v Nagiosu používám plugin , který jednoduše zkontroluje dostupnost aktualizací. Přestože je u pluginu napsáno, že nepotřebuje roota ani sudo, tak sudo pro nrpe mám nastaveno (hlavně pro jiné pluginy).

No a teď to přijde, mám několik serverů, které mají stejnou verzi OS, kernelu, atp. a vůči jednomu z nich mi Nagios vypisuje dostupnost aktualizací a vůči ostatním ne. V messages žádná selinux chyba, sealert taky čistý a přesto, když dám setenforce 0, tak mi to funguje i na zbylých.

Zkoušel jsem pomocí sesearch porovnávat selinuxí výjimky, ale k ničemu to nevedelo.

Když jsem v nrpe.cfg zapnul debug, tak mi to samozřejmě píše tu známou bug chybu "nrpe[2009411]: WARNING: my_system() seteuid(0): Operation not permitted", nicméně to píše i na serveru, kde to funguje.

Nagios server jede na C7 a klienti jsou RHEL8.

Info na závěr je, že mě to samozřejmě fungovalo na všech serverech ani nevím kdy to na některých fungovat přestalo (možná nějaké aktualizace).