- A hozzászóláshoz be kell jelentkezni
- 2160 megtekintés
Hozzászólások
This patch by Stephen Smalley addresses the case where "alien" SELinux security labels need to be written to the local filesystem, for example, in the case of building RPMs where the local policy is different to the policy on the system where the RPM is to be installed.
...
The way this works is to allow locally invalid labels to be written to disk by certain users ...
Hát nem is tudom. Ennek olyan exploit szaga van. Miért kell a "vanilla" kernelbe is ilyen lehetőség? Aki csomagot akar terjeszteni, az vagy foltozza meg a saját kernelét, vagy építsen csomagot 2 lépésben: "permissive" módban (esetleg SELinux nélkül) építse a csomagot, és "enforcing" módban tesztelje.
Nincs véletlenül grsec-es CentOS-szerű disztribúció?
- A hozzászóláshoz be kell jelentkezni
exploit?
--
"When in doubt, use brute force."
- A hozzászóláshoz be kell jelentkezni
Nem én akartam feltenni a kérdést, de ha már feltetted, köszi. Engem is érdekel, hogy mit is akart jelenteni ebben a kontextusban. Elsőre nem tiszta.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
szerintem sokan kategorikusan keverik a security flaw es vulnerability kifejezesekkel
--
"When in doubt, use brute force."
- A hozzászóláshoz be kell jelentkezni
egen
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Igazad van, itt inkább a "security flaw" lett volna megfelelő.
Igazából úgy értettem, hogy ebből elméletileg exploitot lehet gyártani. Ha valaki rá tudja venni valahogy a kernelt, hogy érvénytelen LABEL-ekkel gyártson fájlokat, akkor esetleg lehet majd olyan LABEL-eket is csinálni, amik megengednek mindenféle kódfuttatást. Világos, hogy körültekintő kódolással ezt elvileg ki lehet zárni, de amit el lehet rontani, azt előbb-utóbb valaki el is rontja.
- A hozzászóláshoz be kell jelentkezni
"Igazából úgy értettem, hogy ebből elméletileg exploitot lehet gyártani."
Nem "ebből", hanem "erre". Mármint a security flaw-re. Exploitot, ami kihasználja a biztonsági hibát.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ha valaki rá tudja venni valahogy a kernelt, hogy érvénytelen LABEL-ekkel gyártson fájlokat, akkor esetleg lehet majd olyan LABEL-eket is csinálni, amik megengednek mindenféle kódfuttatást.
No offense, de ismered te az SELinuxot? Nem a labelen múlik a kódfuttatás, hanem a policy allow szabályain. Ha van érvénytelen labeled, de nincs rá policy-d: minden deny. Ha van szabályod a policyben egy labelre, akkor az nem érvénytelen.
--
SELinux, Xen, RHEL, Fedora: http://sys-admin.hu
- A hozzászóláshoz be kell jelentkezni
Tessék egy picit tovább olvasni:
The way this works is to allow locally invalid labels to be written to disk by certain users (namely, those with the standard CAP_MAC_ADMIN capability and the mac_admin SELinux permission).
Magyarul: a fent jelzett capabilityvel és mac_admin rule-lal felruházott felhasználók (nagyon nincs mindenkinek ilyenje) érvénytelen labellel tudnak ellátni bizonyos fájlokat. Erre akkor lehet szükség, ha a policydben nem szerepel olyan type, amelyet neked mindenképpen fel kell használnod (pl. policy modul készítése).
Jelenleg az SELinux nem képes külső policy adatbázist használni, tehát minden definíciónak a lokális policyben kell szerepelnie. Ha én mondjuk 3rd party vendor vagyok és egy ügyfélnek készítek egyedi csomagot, akkor nem biztos, hogy elvárható, hogy odaadja a policyjét tesztelésre, viszont megmondhatja, hogy milyen műveleteket és milyen type-okat kell majd a csomagba tenni.
For security purposes the system will treat those files as if they were not labeled, which means that no normal application will be able to interact with them.
Tehát a labelek ott lesznek, de a lokális szubjektumok nem tudnak hozzáférni (a.k.a. unlabeled file-ok). Exploit kizárva.
Még valami: az SELinuxról ne csak a targeted, hanem a strict policy is jusson eszedbe.
--
SELinux, Xen, RHEL, Fedora: http://sys-admin.hu
- A hozzászóláshoz be kell jelentkezni
Exploit kizárva.
:)
- A hozzászóláshoz be kell jelentkezni
Ha én mondjuk 3rd party vendor vagyok és egy ügyfélnek készítek egyedi csomagot, akkor nem biztos, hogy elvárható, hogy odaadja a policyjét tesztelésre, viszont megmondhatja, hogy milyen műveleteket és milyen type-okat kell majd a csomagba tenni.
Ez nem életszerű példa. Nem életszerű, hogy az ügyfél annyira paranoiás, hogy nem adja ki a policszijét tesztelésre, de simán föltesz egy harmadik cégtől származó csomagot.
Biztos, hogy a RedHat miatt került be ez a folt, és biztos, hogy amiatt, hogy a Fedora-hoz készülő ilyen-olyan rpm-eket könnyebb legyen legyártani (ne kelljen 2-3 virtuális gép a csomagépítéshez és a teszteléshez). Pedig szerintem ezt egy "how-to" oldalon, vagy Fedora fórumban kellene tartani (részletes leírással), és nem a "vanilla" kernelben.
- A hozzászóláshoz be kell jelentkezni
Ez nem életszerű példa. Nem életszerű, hogy az ügyfél annyira paranoiás, hogy nem adja ki a policszijét tesztelésre, de simán föltesz egy harmadik cégtől származó csomagot.
Pedig életszerű: az ügyfélnél használt policy bináris, nem adja oda a vendornak. A vendor viszont az általa gyártott policy modult forrással együtt adja át az ügyfélnek.
Hidd el, nem csak a Red Hat foglalkozik SELinuxszal, sokan csinálnak még egyedi policyket, nekik nagyon jól jön ez a funkció. Igazából nem értem a felháborodásodat: ha targeted policyt használsz, hiszen a security context az extended attribútumokban van tárolva, ez olyan, mintha megmondanád, hogy tilos ezt testreszabni...
--
SELinux, Xen, RHEL, Fedora: http://sys-admin.hu
- A hozzászóláshoz be kell jelentkezni