Privilégium nélküli mount-ok

Kernel

Számos filerendszerrel, filerendszer kezeléssel kapcsolatos patch vár arra, hogy sorra kerüljön a 2.6.25-ös kernel nemsokára megnyíló "merge" ciklusában. Ezek közül az egyik a Szeredi Miklós által fejlesztett "unprivileged mounts", azaz "privilégium nélküli mount-ok" nevű. A patch - ahogy a neve is mutatja - lehetővé teszi kiemelt privilégiumokkal nem rendelkező felhasználói processz számára a mount() rendszerhívás sikeres végrehajtását bizonyos előfeltételek teljesülése esetén. Ez a megoldás hozzájárul ahhoz, hogy a felhasználó rugalmasabb felhasználói környezetet alakíthasson ki, illetve szükségtelenné teszi a setuid-es mount használatát.

Egyesekben felmerülhet kérdés, hogy mi szükség van erre a megoldásra, hiszen a felhasználók évek óta tudnak privilégium nélkül mount-olni. A válasz az, hogy a jelenlegi mechanizmusnak számos hiányossága van. Minden egyes privilégium nélküli mount-ot engedélyezni kell a /etc/fstab file-ban. E mechanizmus egyszerű helyzetekben - például a felhasználó számára lehetővé tenni a CD vagy az USB pendrive mount-olását - működő megoldás lehet, de bonyolultabb esetekben - például amikor a felhasználó FUSE filerendszereket akar mount-olni - már nem hatékony.
Emellett a meglevő mechanizmus igényli, hogy a mount segédprogram "setuid root"-os legyen. Minden setuid-os bináris potenciális biztonsági rés, tehát a rendszerből való eltávolításuk nagyonis kívánatos. Amellett, hogy az "unprivileged mounts" segít megszabadulni a "setuid root"-os mount-tól, policy-alapú felügyeletet ad a mount / umount felett a rendszeradminisztrátor kezébe. Szóval, előzetes hírek szerint - hacsak valami komolyabb probléma közbe nem jön - a privilégium nélküli mount patch-nek jó esélye van arra, hogy bekerüljön a 2.6.25-ös kernelbe.

A cikk elolvasása jelenleg csak LWN előfizetők számára lehetséges. A HUP támogatóinak köszönhetően azonban HUP olvasóknak lehetőségük van az infókhoz hamarabb hozzájutni.

( trey | 2008. 01. 17., cs – 15:16 )

Korábban írtam, hogy a HUP támogatóinak adományából előfizettem az LWN-re, egy évre. Lehetőségem van az ott olvasható cikkeket kifele publikálni egy privát linken keresztül, de nem vagyok benne biztos, hogy ennek a funkciónak "normális használatába" belefér az, ha belinkelem egy nagyobb látogatottságú oldalon. Ezt még lelevelezem az illetékesekkel. Addig forrás nélkül álljon itt a cikk.

--
trey @ gépház

Na igen, de 1 het utan szabadon olvashato, annyit meg ki lehet birni, foleg mivel az LKML-t is olvasom, igaz csak futolag, de legalabb valami ralatasom van, hogy epp mit csinalnak arrafele az emberek es mit nem ... Na persze attol jo otlet ilyet csinalni trey, bocsi, nem ezt ohajtottam ketsegbe vonni, persze.

( sartek | 2008. 01. 17., cs – 15:34 )

"a CD vagy az USB pendrive mount-olását"
az automount nem erre valo? a usernek van irasjoga a dolgokhoz ha jol tudom, es nem kell legyen az fstabba!? csak kerdem

( bervi | 2008. 01. 17., cs – 15:48 )

remek. már csak 1-2 grsec-szerű dolgot kéne beletenni (pl. pax igazán mehetne bele)

tényleg, mi is lesz itt valamelyik következő kiadásban? valami über megoldás rémlik, amit szeretnének beletenni (ilyen sec. dolog)

"The goal of the PaX project is to research various defense mechanisms
against the exploitation of software bugs that give an attacker arbitrary
read/write access to the attacked task's address space."

"MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at."

Megneheziteni egy kod hiba kihasznalsat vs. ujabb hozzaferes szabajzasi mod.

Az hogy egyenlőre nincs olyan módszer, ami 100% biztonsággal örökre védene a programhibák ellen. Addig meg bármi cucc a körülötte keltett marketing hype-al arányos méretű hamis biztonságérzetet kelt. A megoldás az, hogy tessék kijavítgatni a buffer overflow-kat, meg off by one hibákat.

Valakik kitalálták hogy a non exec stack az ultimate solution. Ja, amíg el nem terjedtek a return-to-libc támadások. És így tovább ez állandó macska-egér harc lesz. A linux kernel persze csendben tartalmaz számos védelmet, ami azért erősen lelassítja egy programhiba kihasználhatóságát.

2.6.23, saját tapasztalat:

- stack layout randomization: a stack 4096 féle virtuális címen kezdődhet, minden indításkor máshol.
- library layout randomization: kb. ugyan ez a dinamikusan linkelt lib-ekre. Egyszerű return-to-libc-ről ennyit.

Ping-of-death jellegű "egy csomag/request és bennvagyok" dolgoknak lőttek. Persze nem csodaszer. Ha valami service ész nélkül újraindulgat (sikertelen támadás == segfault, gondolom ez trivi) akkor ezek a cuccok nem védenek, előbb utóbb stimmelni fog a layout, ezt is kipróbáltam.

Mindezek ellenére lehet csinálni return-to-libc-t csak ahhoz rendelkezni kell a támadott bináris pontos másolatával és strippelt binárisok esetén komoly szívás megtatálni a PLT-ben a keresett fuggvényt. A PLT fix futásról futásra.

Pontosan nem tudom. Lehet hogy nem ez a pontos neve. Régen ki lehetett találni, hogy a dinamikus linker milyen belépési pontokkal teszi le a lib függvényeket. Ezek a címek fixek voltak, de 2.6.23 esetén futásról futásra mások. Sikeres return-to-libc támadáshoz az adott binárisban kell megtalálnod azt a call-t ami azt a függvényt hívja, amit használni akarsz. Strip-elt bináris esetén én kifogytam a tudományból.

( Oscon | 2008. 01. 18., p – 09:58 )

E mechanizmus egyszerű helyzetekben - például a felhasználó számára lehetővé tenni a CD vagy az USB pendrive mount-olását - működő megoldás lehet, de bonyolultabb esetekben - például amikor a felhasználó FUSE filerendszereket akar mount-olni - már nem hatékony.

És most emiatt az uram bocsá igencsak szűk réteg (ótómata FUSE-izó user) miatt kell megint szétverni egy évek óta működő szisztémát. grat. :-(

Emellett a meglevő mechanizmus igényli, hogy a mount segédprogram "setuid root"-os legyen. Minden setuid-os bináris potenciális biztonsági rés, tehát a rendszerből való eltávolításuk nagyonis kívánatos.

Ezt nem vitatom, de azért ez az említett setuidos program (mount) azért már jópár éves, megkockáztatom hogy kinőtte gyerekbetegségeit, és talán nem kellene szétverni mint működő rendszert.

Megkockáztatom azt is, hogy a setuid-rootos mount ma már nem jelent akkora biztonsági rizikót, mint egy kezdetleges "privilégium nélküli mount patch" közvetlenül a kernelben...

Nagyon remélem megoldják úgy hogy a kernelben "opcionális" lesz. Tehát ha akarom, akkor enélküli kernelt használok.

-----------------

Nem a zsömle kicsi, a pofátok nagy...

Arra értem a "szétverni"-t, hogy kvázi pl. az fstab jóeséllyel megszűnik a jelenlegi formájában.

Ill. talán még a jelenlegi udev-es rendszer is értelmét veszti. Mert minek kell pl. a kötetcimke alapú becsatolás, ha mindenki azt csatol be a rendszerbe, és oda ahova és amit akar ? A kettő valahol üti egymást.

Legalábbis nekem úgy tűnik. Megdugom a kasznit egy usb pendrive-al, udev érzékeli a kötetcimkét fstab alapján lehetőséget biztosít az usernek, hogy becsatolja a megadott opciókkal.

Ha unprigvileged mount van, akkor ugye kvázi nincs fstab. nem tiszta az egész. (nekem). vagy mi van akkor ha van egy fstab bejegyzés a kötetcimkére, de az eszköz amit becsatolnék unprivileged mount ? Akkor máris van egy logikai ellentmondás, amiből vagy kernelpanic (=local DoS) lesz, vagy high critical szintű local security bypass.

Akkor ugye vannak bizonyos biztonsági opciók, mint a noexec, nodev, stb. Ha user csatol be közvetlenül akkor nyílván ezek sem játszanak, ergo idegen binárist könnyebben juttat be a rendszerbe. mi értelme van a /home-t noexeccel becsatolni ha /home/badguy/pendrive1-en meg futnak a binárisok, mert user úgy csatolja be ahogy akarja...

De azért nyugtassuk magunkat azzal, hogy legalább egy setuid rootos programmal kevesebb.

meg mondjuk talán nem volna jó mindenféle fájlrendszert userrel becsatoltatni. Pl. sysfs, tmpfs, proc meg hasonlókat... marha jól nézne ki egy "klón-sysfs" a /home/badguy/sys/devices/system-ben pl. ... biztonsági szempontból.. :(((

Mivel nem írtál fájlrendszertől való függőséget, valószínűleg nem egy plusz "nopriv" mount() opció lesz, amit mondjuk eszköznévhez/partícióhoz/stb. biggyesztve az fstabban, az fstab kvázi "lepasszolja" magáról az eszközzel való esetleges tennivalókat. Ez a lehetőség ugye fájlrendszerfüggő, mert ha az adott fájlrendszertípus nem ismeri a nopriv-et akkor nem fog vele foglalkozni.

Persze ez mind találgatás amit írok, mert én nem vagyok LWN előfizető, nem látok bele abba hogy miképpen is működik a patch, de a cikk alapján meglehetős fenntartásokkal fogadom.

És akkor még nem volt szó a különféle alternatív biztonsági megoldásokról melyek további korlátozási lehetőséget biztosítanak a mount() jelenlegi formájára. Ezt is mind át kell variálni (=szét kell verni). Mindezt azért mert van egy pár százaléknyi elmeroggyant, aki össze vissza csatol be a rendszerébe mindenféle fusis fájlrendszert és lusta rá sudo-s szkripteket csinálni ha az fstab-bal user kapcsolóval nem tudja megetetni. Inkább turjunk kernelt mind ahányan csak vagyunk... :((

------

Nem a zsömle kicsi, a pofátok nagy...

v6 -> v7:

 - add '/proc/sys/fs/types/<type>/usermount_safe' tunable (new patch)
 - do not make FUSE safe by default, describe possible problems
   associated with unprivileged FUSE mounts in patch header
 - return EMFILE instead of EPERM, if maximum user mount count is exceeded
 - rename option 'nomnt' -> 'nosubmnt'
 - clean up error propagation in dup_mnt_ns
 - update util-linux-ng patch

v5 -> v6:

 - update to latest -mm
 - preliminary util-linux-ng support (will post right after this series)

v4 -> v5:

 - fold back Andrew's changes
 - fold back my update patch:
    o use fsuid instead of ruid
    o allow forced unpriv. unmounts for "safe" filesystems
    o allow mounting over special files, but not over symlinks
    o set nosuid and nodev based on lack of specific capability
 - patch header updates
 - new patch: on propagation inherit owner from parent
 - new patch: add "no submounts" mount flag

v3 -> v4:

 - simplify interface as much as possible, now only a single option
   ("user=UID") is used to control everything
 - no longer allow/deny mounting based on file/directory permissions,
   that approach does not always make sense

v1 -> v3:

 - add mount flags to set/clear mnt_flags individually
 - add "usermnt" mount flag.  If it is set, then allow unprivileged
   submounts under this mount
 - make max number of user mounts default to 1024, since now the
   usermnt flag will prevent user mounts by default

- Miklos Szeredi @ [patch 00/10] mount ownership and unprivileged mount syscall (v7)

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

akkor te sem vagy az olyan rendszerek híve, amik mindent megcsinálnak helyetted, szereted kézben tartani, hogy mi mit csinál.
igen érdekes lesz, hogy minden user azt csatolgathat, amit akar, de szvsz ennek lesznek hátrányai is ... pl megjelennek az olyan fincsi programok, amik direkt erre mennek rá, hogy egy file-t felcsatolnak (N+1)*M-szer ls ezzel legyilkolják a VFS-t ...

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Van egy rendszerszintű számláló, amely nyilvántartja az unprivileged mount-ok számát. Ha ez eléri a maximumot, addig nem lehetséges új unprivileged mount-ot csinálni, amíg valaki nem umount-ol előtte. A vfsmount struktúrába bekerül egy új mező (uid), így kernel userre lebontva tudni fogja, hogy ki mennyit mount-olt. Később igény esetén system wide limit helyett a limit akár userre is megadható lenne.

--
trey @ gépház

( bervi | 2008. 01. 18., p – 11:53 )

a policy dologra kíváncsi lennék...

egyébként a levélben az áll, hogy

"After much sitting in -mm, Andrew dropped this patchset due to
conflicts with other stuff. It would be nice, if it could be reviewed
in time for 2.6.26 (2.6.25 is closed as far as I understand)."

nem találtam olyan választ, ahol ezt cáfolták volna

( pinyo_villany | 2008. 01. 18., p – 22:53 )

patch:
[00/10] mount ownership and unprivileged mount syscall (v7)
[01/10] unprivileged mounts: add user mounts to the kernel
[02/10] unprivileged mounts: allow unprivileged umount
[03/10] unprivileged mounts: propagate error values from clone_mnt
[04/10] unprivileged mounts: account user mounts
[05/10] unprivileged mounts: allow unprivileged bind mounts
[06/10] unprivileged mounts: allow unprivileged mounts
[07/10] mount ownership and unprivileged mount syscall (v7)
[08/10] unprivileged mounts: make fuse safe
[09/10] unprivileged mounts: propagation: inherit owner from parent
[10/10] unprivileged mounts: add "no submounts" flag

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

http://lkml.org/lkml/2008/1/16/96

Nah, ha csak egy nosubmnt-al kell ellátni az összes fájlrendszert az fstabban és marad a régi rendszer, az már sz'tem alapvetően jó. :-)
A régi rendszer egyszerűen túl jól megy sz'tem ahhoz hogy csak úgy kidobjuk.

SZERK:A régi rendszer egyszerűen túl jól megy sz'tem ahhoz hogy csak úgy kidobjuk.

Mentségemre szóljon hogy jópár éve debiant használok, és alapvetően immunis vagyok az olyan változásokra, melyek számomra akármilyen pluszmunkát is jelentenek, és nem látom hogy számomra - önző disznó na! - értelme van. Legyen az egy új ACPI megvalósítás a kernelben, UTF-8, vagy unprivileged mount. :)))

/SZERK_vége.

Esetleg még egy apró megjegyzés: azért a fejlesztő is látja hogy potenciálisan gyengítheti a motyója a rendszerbiztonságot:

For "safe" filesystems allow unprivileged mounting and forced
unmounting.

A filesystem type is considered "safe", if mounting it by an
unprivileged user may not cause a security problem. This is somewhat
subjective

---------

Nem a zsömle kicsi, a pofátok nagy...

maradunk a debiannal és én a 2.6.22.y kernelnél :D ezt már eldöntöttem majd 2.6.26 vagy 2.6.28-ra átváltok, ha olyannak találom, de addig még sok bit folyik át a duna alatti vezetékeken.

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1