( _Franko_ | 2024. 05. 06., h – 16:59 )

Azaz ha már van UID=0 processzed, akkor ki/be kapcsolgatható. Ez rendben is van.

Lófaszt van rendben, megszakad a processz, aztán ott marad noexec nélkül a /tmp. Másrészt milyen megoldás az, hogy kinyit egy "nagykaput" az update idejére?

De amíg nincs, _és_ a támadó robotja által használt n+1 darab jogosultságemelésre szolgáló exploitja elhasal rajta, addig teljesen jó arra, hogy lassítsa/nehezítse a dolgát.

Nem lassítja meg nehezíti, baszki, elmegy mellette, mintha ott se lenne. Nem az van, hogy noexec esetén 100 perc, noexec nélkül 0 perc a törés, hanem mindkét esetben 0 perc a bináris futtatásának lehetősége, mintha a noexec ott se lenne. Semmit nem lassít a noexec flag a 2.6.39 kernel óta, az meg nem ma jött ki.

Debian származékokon alapvetően nincs SELinux - fel lehet kalapálni, igen, de kellően méretes szívásokba lehet vele belefutni, pláne 3rd party repókkal...

Mondom SELinux és társai.

Egyik sem a bölcsek köve, ez az egyik.

Leírom lassan: ha nincs SELinux és társai használva, akkor a noexec semmi ellen nem véd, megkerüli minden, mert meg lehet kerülni és meg is kerülik, az első megkerülő exploit dokumentációja 7 - azaz hét - éve arról ír, hogy hagyd a picsába a noexec-et, semmire se jó, használj helyette SELinux és társait. Ezt követően, ha van SELinux és társai, akkor meg semmi értelme a fájlrendszerre a noexec flagnek, mert SELinux és társai tudják ezt per process, per group, per directory is állítani.

Aki az utóbbi években noexec-et akar fájlrendszerre, hogy az majd véd bármit is, annak nulla kurrens security ismerete van, amit tud, az több mint 10 éves tudás. Nem mondom, el lehet karcolni a piacon 10 éves tudással is, csak néha pofára lehet esni, amikor kiderül az elavult tudás a területen.