felügyelhetõ LD_PRELOAD

 ( bAndie9100 | 2013. február 7., csütörtök - 16:50 )

A rendszernaplózással foglalkozva magam se tudtam spekulálás nélkül elmenni azon tény mellett, hogy a linux disztribúciók 666-os joggal telepítik a sysloggolásra használt /dev/log socket-ot.
A megosztott rendszereken, ahol nincsenek chroot-ban az alacsony bizalmi szintũ folyamatok, ez loghamisítást, tárterület elhasználást és más nem várt fejfájást okozhat.
Eddig akiknek nem tetszett, levették 660-ra és csoportokba sorolták azokat a folyamatokat, akikben megbíznak és használhatják a sysloggert.

Nekem egy rugalmasabb ötletem volt, amit függvény-felülírással akarok megvalósítani.
A lentebb közölt kód environmentekbõl állapítja meg, mi mehet és mi nem mehet a syslogba.

Ez nagyon jónak bizonyult "buta" programok megneveléséhez, ahol nem kell számítanuk, arra, hogy a preload-olt függvényeket ki akarják kerülni.

Kérdésem az lenne, hogy hogyan lehetne biztonságossá tenni a mégalacsonyabb bizalmú folyamatokhoz csak a futtatási model (<- ezt nem tudom érthetõbben kifejezni) kihasználásával, tehát no chroot, no jail?

Az elején igaz, kimentem az env-eket, hogy a program már ne tudja átállítani (perl-lel teszteltem $ENV{"RGDLOG_FACILITY"} változó írásával de nem hívott setenv()-et, nem tudom végülis ez az environment, hol található), de végtére a folyamatnak tudtommal van írási joga arra *rgdlog_facility memóriaterületre, tehát kijátszható a preload-olt függvény.
Ahogyan kijátszható az is, hogy az függvény-felülírásra használt dlsym()-met alkalmazva az alárendelt program is kikeresse a libc-bõl a nem átírt függvényt és azt hívja meg az enyém helyett. Ennek a megakadályozásához mi kell? Írjam felül a dlsym()-et?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egész ügyes megoldás.
A probléma csak annyi, ahogy te is látod, hogy ez nem ad 100%-os biztonságot. Egyik lehetőség az lenne, hogy a libc-t patkolod meg, így nem kell LD_PRELOAD.
Ezzel még mindig nem lennél teljesen védett, mert a process hozzáfér a /dev/log-hoz és kikerülheti az openlog()-ot (saját openlog()/syslog() implementációval).
Szerintem az egyetlen megoldás a syslog daemon oldali védelem ahogyan ezt több syslogd is csinálja (rsyslog, journal, stb). Lásd unix(7): SCM_CREDENTIALS
Így a syslogd-ben lehet szűrni és az illetéktelen szemetelőket ignorálni. Ez továbbra sem véd az ellen, hogy egy process rákapcsolódjon a /dev/log-ra és DOS-olja a syslogd-t (ez ellen van az általad írt 660).

Idézet:
kikerülheti az openlog()-ot

az utolsó függvényt nézted? a connect()-ot is megzaboláztam, épp azért hogy nem akarja magának implementálni a syslog()-ot és közvetlenül írni a socket-ra.
a connect() megérzésem szerint egy mélyebb szintũ függvény, ezt tudja helyettesíteni valamivel a processz?

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

"a connect() megérzésem szerint egy mélyebb szintũ függvény, ezt tudja helyettesíteni valamivel a processz?"

Persze, csinalhat direktben syscallt.

--
"You're NOT paranoid, we really are out to get you!"

Ez se kell: statikusan linkeli a libc-t, és az egész dl-es varázslás nem ér semmit.

typós ez a táblázat az rsyslogos lapon? honnan tudja hogy _EXE néven melyik Trusted Property-rõl van szó a kettõ közül? :D

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Idézet:
megoldás a syslog daemon oldali védelem

http://code.google.com/p/logwall/

ehez mit szólsz? beülök a syslog daemon és a log socket közé átjátszónak.
így nem kell, hogy a syslogger külön támogassa a credential-alapú szũrést.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Természetesen ez kevésbé tűnik kijátszhatónak, mint az eddigi próbálkozások. Annyi a baja, hogy ez így +1 daemon, ráadásul perl.
Én továbbra is úgy gondolom, hogy ennek a funkciónak a syslogd-ben a helye. Rsyslog-ban nem tudom mennyire lehet ilyen bonyolult szabályokat írni ami ezeket a trusted property-ket vizsgálná.
Az nxlog-hoz csak egy kisebb kiegészítés kéne az im_udp modulba, hogy az SO_PEERCRED/SCM_CREDENTIALS által visszaadott mezőket eltárolja a logban (ahogy az rsyslog teszi), majd ezeket a syslog mezőkkel kombinálva itt is lenne lehetőség hasonló bonyolultságú szűrőfeltételek írására.

Miert bantjuk szegeny Perlt? :-(
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem maga a perl a baj, én is szeretem. Ennek ebben az esetben csak az a baja, hogy nagy mennyiségű log előszűrése esetén valószínűleg kicsit erőforrásigényesebb a perl miatt.

Lenyegeben nem eroforrasigenyesebb, mint ugyanez C-ben megvalositva. A Perl pont azert jo, mert az interpreter hihetetlen gyors.

No persze ez implementacio kerdese is. De azt ugye neked se kell mondani, hogy C-ben is lehet szar teljesitmenyu kodot irni... szoval ennyi.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

igen, hátránya a modularitásnak, hogy egyel több folyamat, de válassza mindenki a neki megfelelõt! :)
az csak az én szegénységem, hogy szkriptnyelven írtam meg, C-ben is megvalósítható.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Kicsit bizonytalan vagyok e teren: a /dev/log -on at hogy lehet logot hamisitani? Tippem nyilvan van, mert a logger nevu utility is kepes erre (tenyleg, ezzel mi a helyzet, mennyire bizol meg benne?), csak nem tudom/ertem, hogy ez hogyan mukod a gyakorlatban.

Illetve en inkabb fekete listaval dolgoznek: kik nem, csak nyilvan ez a Linux jogosultsagrendszereben elkepzelhetetlen.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A gyakorlatban így működik:

open(FD, /dev/log);
write(FD, "akármi");

Mivel a socket-re így akármi beküldhető, így egy program azt mond amit akar.

itt tudja valahogy ellenõrizni a socketon listen()-elõ program, hogy ki van a túlvégen, nem?
milyen infókat lehet róla megtudni?

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

Ha jol tudom, nem sokat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, erre van az SCM_CREDENTIALS.

logger -p kern.emerg -t linux "Huston, we have a kernel panic"

próbald ki! (nem destruktív)
ráadásul legtöbb helyen az emerg minden user termináljára is ráírja az akármit.

megában a loggerben teljes mértékig megbízok, azt teszi amit elvárok tõle.
bár kicsit érdekes, hogy nem az openlog()-ban adja meg a facility-t :/

különben igenis elképzelhetõ a feketelistás ki-férhet-hozzá-a-sysloghoz dolog, amit viszont kevésbé tudok elfogadni!
ha beállítod g-w,o+w jogokat a /dev/log -ra és mondjuk a nolog csoport tulajdonába adod a fájlt, akkor a -w jog fog érvényesülni rájuk és így aki a nolog csoportban van, fekete listán van.

ez azért nem tetszik nekem, mert az 'ugo' hozzáférési szinteket én alárendelt szintekként képzelem el, tehát ha a fájl tulajdonosa vagyok, legalább annyi jogomnak kell legyen, mint a nem tulajnak, mivel jogosultságok magunktól eldobni megengedett (szerezni nem) - az én ideámban. tehát pl. egy radikális 046 jogú fájlnál, fogom magam, nem azonosítom magam a fajl owner-jeként és akkor máris tudom írni a fájlt.

persze ha így lenne és az 'ugo' nem mellérendelt szintek lenének, akkor nem kéne 3 bájt a jogok ábrázolásához :)

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

a syslog nem azert van hogy minden program, aki nem akar sajat loggal veszodni, megnyitja ezt majd beleszorja a fajasat? akkor meg miert jo korlatozni?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

mert ezáltal lehet hamisítani/túlhasználni.
nem desktop környezeten érdekes ez a probléma.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE

A tulhasznalatot a te megoldasod sem vedi ki, es igazabol mivel UNIX socketrol beszelgetunk, nem is nagyon lehet limitet/throttlingot allitani ra. A hamisitas meg reszben szinten megoldhato a fent irt modozatok egyikevel, reszben pedig azert azokban a binarisokban amit en rakok fel a gepre, abban megbizok, ha meg valaki mas binarisai futnak a gepen, akkor az a legkisebb problmeam, hogy logot hamisit (pontosabban mas neveben logol).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ezt a programon belulrol sehogy sem* tudod enforce-olni, a sajat kodjan belul azt csinal, amit akar. Valamilyen MAC frameworkben erdemes itt gondolkodni.

*: de, ha megfogod valami SFI-jellegu megoldassal, de azert az kicsit overkill. :)

--
"You're NOT paranoid, we really are out to get you!"