Dotaz: Aktualizace CentOS rozbila selinux pravidla na několika systémech

[shak]

Ahoj. Už po několikáté se mi stalo to, že aktualizace systémů (CentOS 6) "rozbila" selinux - konkrétně balík shorewall. Obvykle řeším pomocí vlastního semodulu či pomocí restorecon po vyhledání fixfiles. Nyní to ale nejde. Mám 2 systémy - poštovní server a webový server. Oba Centos 6 64bit, oba instalovány a aktualizovány stejným způsobem. Přesto na webovém serveru vše OK, na poštovním je v audit logu:

avc:  denied  { getattr } for  pid=1761 comm="sh" path="/sys/module" dev=sysfs ino=581 scontext=system_u:system_r:shorewall_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
...

A to po nahrání vlastního semodulu, předtím si to stěžovalo na search oprávnění. Na obou serverech jsou stejné verze shorewall a ostatních balíků, kontext na souborech sedí, "semanage fcontext -l | grep shorewa" vrací stejný výstup na obou serverech. I přesto se zdá, že shorewall inicializuje firewall normálně - evidentně má ale s něčím problém.

Čím může být způsobený tento problém?

Odpovědi

[michich]

No a máš v tom vlastním modulu teda něco jako allow shorewall_t sysfs_t:dir getattr? Ten denial by celkem odpovídal tomu, co dělá funkce loadmodule() v Shorewall-core/lib.common.

Shorewall v CentOS 6 není. Máš ho asi z EPEL nebo odjinud. Takže mě ani nepřekvapuje, že distribuční selinux-policy s ním nepočítá.

[shak]

Ne, dál už jsem to neřešil. V tom modulu jsem povolil jenom search. Jistě, jedna cesta je zkoušet na X krát audit2allow, nicméně jak je možné, že na jednom stroji to funguje dobře a na druhém ne? Jakým způsobem se aktualizují selinux pravidla? Koukal jsem se do rpm selinux-policy-targeted vč. jeho skriptů, ale nějak mi to není jasné? To se nějak dynamicky dokompiluje k již nasazeným pravidlům? V jakém balíků a proč může vzniknout ta nekonzistence - na jednom stroji funguje, na druhém ne? A ano, je z EPEL.

[michich]

jak je možné, že na jednom stroji to funguje dobře a na druhém ne?

A to máš na obou strojích úplně stejnou konfiguraci shorewallu? Pokud ne, tak je možné, že na jednom z nich se shorewall pokouší načíst nějaký conntrack helper modul a na druhém ne.

Jakým způsobem se aktualizují selinux pravidla? Koukal jsem se do rpm selinux-policy-targeted vč. jeho skriptů, ale nějak mi to není jasné? To se nějak dynamicky dokompiluje k již nasazeným pravidlům?

V %post to volá semodule -B, což slinkuje *.pp moduly (včetně tvého) do výsledné policy.

[shak]

Na obou strojích je podobná konfigurace, liší se jen povolenými porty, ale funkce používá stejné. Taktéž se mi dříve na jiných systémech stalo, že přestal po aktualizaci fungovat zabbix klient. Rovněž se jednalo o stejnou verzi, jen to byl 32bitový CentOS.

Když vypíšu "sesearch --allow -t shorewall_t", pak si výpis na obou server nepatrně liší. Záhada je proč. Pomocí vlastního modulu bych to dokázal opravit ... pořád ale další aktualizace může něco rozbít a tak bych rád věděl při čem se to rozbíjí a co může mít za následek rozdílná pravidla na obou serverech? Vlastní moduly, různé nastavení sebool? Dá se z něčeho zjistit, jestli při aktualizaci nenastala někde chyba? Logy jsem prošel a aktualizace byly úspěšné.

[shak]

Vzal jsem chybějící pravidla z funkčního systému a udělal modul. Dostal jsem se k tomuto:

module mujmodul_shorewall 1.0;

require {
        type shorewall_t;
        type prelink_mask_t;
        class process sigchld;
        class fd use;
        class fifo_file { ioctl read write getattr lock append };
}

#============= shorewall_t ==============
allow prelink_mask_t shorewall_t : process sigchld ;
allow prelink_mask_t shorewall_t : fd use ;
allow prelink_mask_t shorewall_t : fifo_file { ioctl read write getattr lock append } ;

... ale ...
semodule -i mujmodul_shorewall.pp
libsepol.print_missing_requirements: mujmodul_shorewall's global requirements were not met: type/attribute prelink_mask_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!

Na tom "nefunkčním" systému neexistuje vůbec prelink_mask_t - "sesearch --allow -t prelink_mask_t" nevrátí nic, na tom druhém vrátí spoustu pravidel. Podle "grep prelink_mask_t /usr/share/selinux/* -R" jsou nějaké pravidla v "/usr/share/selinux/devel/include/admin/prelink.if".

Jak zjistím, který modul tato pravidla definuje a jak je tam dodat?

[shak]

Reinstalace ukázala na teoreticky možný problém:

etckeeper: pre transaction commit
  Instaluje se  : selinux-policy-3.7.19-260.el6.noarch                                                                                        1/2 
  Instaluje se  : selinux-policy-targeted-3.7.19-260.el6.noarch                                                                               2/2 
semodule: link.c:840: alias_copy_callback: Assertion `base_type->primary == target_type->s.value' failed.
etckeeper: post transaction commit
  Verifying     : selinux-policy-targeted-3.7.19-260.el6.noarch                                                                               1/2 
  Verifying     : selinux-policy-3.7.19-260.el6.noarch

Na tom druhém dobrém serveru ta Assertion hláška není.

[shak]

Nakonec jsem to vyřešil vymazáním politik z /etc/selinux a jejich přeinstalací a postupnou obnovou mých definicí. Možná ten problém vznikl díky tomu, že základní politiky nyní obsahují definici pro port 10026 jako dspam zatímco já ho měl jako další pro amavis. Vážně nevím, každopádně je to celé podle mě špatně navržené - jak selinux resp. jeho údržba obecně až po aktualizaci v centos/rhelu (každá aktualizace mění hromady kontextů aj.).