Strona główna / Blog / SELinux fixfiles: analysis pending

Blog · analiza

SELinux fixfiles: podatny kod był obecny od lat, ale Red Hat nadal ustala, które RHEL są affected. Jak VM ma działać w stanie „analysis pending”

CVE-2026-19079 dotyczy skryptu fixfiles w policycoreutils. TOCTOU race między find i chcon pozwala lokalnemu attackerowi podmienić element ścieżki na symlink i doprowadzić do zmiany SELinux label na arbitralnym pliku. Red Hat podaje równocześnie, że podatny /tmp cleanup code path istnieje od wielu lat, ale product analysis nadal musi ustalić, które dokładne wersje RHEL rzeczywiście zawierają podatny kod i wymagają backportu.

CVE-2026-19079: TOCTOU między find i chcon w fixfiles → zmiana SELinux label dowolnego pliku (symlink).
Stan vendora: podatny /tmp cleanup istnieje od lat; Red Hat nadal ustala affected wersje RHEL (analysis pending).

Najtrudniejszy stan VM: brak pełnej affectedness

Systemy potrzebują stanów innych niż tylko affected/not affected: under investigation, needs evaluation, out of support scope. Under investigation nie oznacza safe — oznacza brak zakończonej analizy i powinno mieć własny monitoring oraz deadline. To ten sam problem, co przy vendorach na różnych etapach oceny: brak decyzji nie jest decyzją „nie dotyczy”.

Mitigation

Red Hat sugeruje używanie restorecon -R / zamiast fixfiles relabel/restore, co omija podatny /tmp path. To ciekawy przypadek workaroundu przez alternatywne narzędzie realizujące tę samą funkcję bez podatnej ścieżki — control lineage warto zapisać wraz z właściwością, którą gwarantuje.

Wniosek

CVE-2026-19079 pokazuje, że VM potrzebuje jawnego modelu niepewności. Brak pełnego vendor assessment nie jest brakiem ryzyka — jest brakiem wiedzy, który powinien mieć własny status i proces ponownej oceny. Pytanie brzmi nie „affected czy nie?”, lecz: czy potrafimy oznaczyć „jeszcze nie wiemy” tak, żeby nie zniknęło z radaru?

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 3 września 2026. CVE-2026-19079 (policycoreutils fixfiles, TOCTOU między find i chcon): Red Hat wskazuje, że podatny /tmp cleanup istnieje od lat, ale product analysis wciąż ustala affected wersje RHEL; workaround to restorecon -R /. Artykuł koncentruje się na jawnym modelu niepewności w VM.

Zapamiętaj jedno

Brak pełnego vendor assessment nie jest brakiem ryzyka — jest brakiem wiedzy. VM potrzebuje jawnego modelu niepewności: stan under investigation / needs evaluation z własnym monitoringiem i deadline, nie utożsamiany z „safe”.