tomld 0.40

Több mint 7 hónapos fejlesztés után elérkeztem a január elején felállított célomhoz: a Tomoyo Mandatory Access Control (MAC) megoldásához fejleszteni egy teljesen automatikus "1 klikkes" megoldást, mely kompromisszumok és mindenfajta felhasználói beavatkozás szükségessége nélkül képes megfelelő módon rendezni az alkalmazások Tomoyo által összegyűjthető hozzáférési szabályait. Ismereteim szerint ilyen automatikus MAC konfigurációs megoldás még nem létezik (fix me), és a nagy disztribútorok is előre gyártott szabályokat szállítanak.

Ez az első stabil verzióm teljes funkcionalitással. Feature lista itt. (Tomoyo része a mainline kernelnek 2.6.30-as verzió óta)

Motivációm az volt, hogy -mivel Tomoyo használata során az derült ki számomra, hogy az eszköz egyáltalán nem felhasználóbarát, annak használata és a szabályok "kézi" beállítása rengeteg időt (visszatérően) és hozzáértést igényel nagy hiba lehetőség mellett- létrehozzak egy teljesen automatikus megoldást. A kézzel létrehozás problémájáról itt olvasható a FAQ egyik bejegyzése.

Saját szervereken teszteltem a fejlesztés alatt a tomld-t megfelelő adat biztonság megteremtése mellett 5 - 130 fős felhasználókkal. Sikerült mostanra úgy létrehoznom szabályokat tomld-vel telepítés után mindenfajta kézi beavatkozás nélkül, hogy miután minden domain kikényszerítő módba kapcsolódott, nem merült fel hozzáférés megtagadás. Igaz, a szolgáltatások száma relatíve kevés és nincs kapacitásom minden use case-t tesztelni, de remélem idővel nagyobb lesz a felhasználói bázis. Az elkészült kb. 2500 sort tartalmazó szabályokat pedig soronként ellenőriztem egyesével, és mindet megfelelőnek találtam.

A tesztelt szolgáltatások: squid, ntpd, apcupsd, apt, firebird, dhttpd, clamav, cupsd, dnsmasq, exim4, postfix, procmail, fetchmail, samba, dhcpd, kvm, unbound, avahi - illetve alkalmazások, úgy mint: firefox, chromium, centerim, lftp, ssh, vncviewer.

Jelenleg még mindig várok Debian fejlesztő jelentkezésére a mentors.debian.net oldalon, aki elvállalja a mentorálást és bejuttatja tomld-t csomagként Debian-ba. (Magyar Debian-os fejlesztő nincs itt köztetek, aki ezt megtenné?) Addig .deb telepítőt terjesztek tomld.tgz-ben. Ubuntu-hoz létrehoztam PPA-t. OpenSUSE-hez csomagot a közeljövőben tervezek készíteni.

Futáshoz feltételek itt. Telepítővel támogatott rendszerek: Debian 6-tól felfelé, Ubuntu 10.10-től felfelé, openSUSE 12.1 (dev).

Bemutató videó a telepítésről Ubuntu alatt itt.

Weboldal | Változások listája | FAQ

A 0.40-es verzió tesztelésében sokat segített szimszon (illetve előtte muczy is), hrgy84 pedig az openSUSE telepítő egy részéhez adott ötletet. Ezúton is köszönöm.

Hozzászólások

Gratulálok, igyekeztem figyelemmel követni a fejlesztést! :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

2500 sort tartalmazó szabályokat pedig soronként ellenőriztem

Ez tetszik :)

Ja igen, legutóbb fetchmail produkált olyan bejegyzéseket, amelyek véletlen részt tartalmaztak, és az algoritmusom nem illeszkedett rá. Ekkor általában elkezdem nézni a bejegyzéseket sorról sorra, aztán azon veszem magamat, hogy totál más dolgokon gondolkodok, de persze a soremelést nyomkodtam közben, ez az idő meg kiesett.. ekkor gyorsan vissza scrollozok, és újra..

Úgyhogy zombi móddal együtt az a végső 2500 olyan 2500 + x :)

Egyenlőre a lapin és a munkahelyi gépemen be van lőve. Tetszik...

Azért desktop környezetben bele lehet futni hozzáférés megtagadásba, de ez nem a tomld hibája (legalábbis ez én eddigi eseteimben), hanem hogy a programokat nem használtam intenzíven. Most már fenn marad :)

Köszi a fejlesztést!

Hm... Olyan mintha nem lehetne kétszer egymás után átmeneti tanuló módba kapcsolni.

Most van az az időszak amikor a domain-ek enforce módba kerülnek, ezzel nincs is baj, kiadom a tomld --learn -t, és örülök.

~30-37mp múlva visszavágja a domain-t enforce módba, de ha a proginak más is kellene, és megpróbálom a tomld --learn -t. Nincs hatása... :(

* sent user request to running daemon for temporary learning mode

de a tomld.log-ban már nincs semmi, percek után sem.

újra kell indítani a tomld-t, és megint kiadni a tomld --learn -t.

140 active domains, 14902 rules
cycle times min/avg/max 1.73/2.86/10.32 sec
used cpu 10.20 %, vm peak 11.0 MB, rss peak 6.6 MB
ended at Sun Aug 28 22:50:24 2011

started at Sun Aug 28 22:50:24 2011
tomld (tomoyo learning daemon) 0.40
Linux version 2.6.38-11-generic-pae (buildd@rothera) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #48-Ubuntu SMP Fri Jul 29 20:51:21 UTC 2011
* mail requested but binary /usr/sbin/sendmail missing
* encrypted fs found
* recursive directories set:
/home/\*/fejlesztes/sajat/eclipse/.metadata/.plugins/
/home/.ecryptfs/xxxxxx/.Private/
* exception domains
/bin/bash /bin/dash /bin/rbash /bin/sh /sbin/init /usr/bin/screen /usr/sbin/sshd /usr/sbin/tomld /usr/sbin/tomoyo-loadpolicy
* new processes using network
/usr/sbin/avahi-daemon
/usr/sbin/cupsd
/sbin/dhclient
/usr/bin/skype
/usr/bin/pidgin
/usr/lib/thunderbird-6.0/thunderbird-bin
/usr/lib/firefox-6.0/firefox-bin
/usr/lib/gvfs/gvfsd-http
* already existing main domains
avahi-daemon cupsd dhclient firefox-bin gvfsd-http pidgin skype thunderbird-bin
* checking policy and rules
/home/szimszon/prg/eclipse/eclipse, domain exists, learning mode on
/sbin/dhclient, domain exists, learning mode on
/usr/bin/gnome-open, domain exists, learning mode on
/usr/bin/gpg, domain exists, learning mode on
/usr/bin/host, domain exists, learning mode on
/usr/bin/pidgin, domain exists, enforcing mode on
/usr/bin/python2.7, domain exists, enforcing mode on
/usr/bin/qlandkartegt, domain exists, enforcing mode on
/usr/bin/rdesktop, domain exists, enforcing mode on
/usr/bin/skype, domain exists, enforcing mode on
/usr/bin/ssh, domain exists, enforcing mode on
/usr/bin/transmission-gtk, domain exists, learning mode on
/usr/bin/wine-preloader, domain exists, learning mode on
/usr/bin/wineserver, domain exists, learning mode on
/usr/lib/apt/methods/http, domain exists, learning mode on
/usr/lib/cups/backend/ipp, domain exists, learning mode on
/usr/lib/firefox-5.0/firefox-bin, domain exists, learning mode on
/usr/lib/firefox-6.0/firefox-bin, domain exists (restart needed), learning mode on
/usr/lib/gvfs/gvfsd-http, domain exists, enforcing mode on
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java, domain exists, learning mode on
/usr/lib/network-manager-openvpn/nm-openvpn-service, domain exists, learning mode on
/usr/lib/thunderbird-5.0/thunderbird-bin, domain exists, learning mode on
/usr/lib/thunderbird-6.0/thunderbird-bin, domain exists (restart needed), learning mode on
/usr/sbin/avahi-daemon, domain exists, enforcing mode on
/usr/sbin/cupsd, domain exists, enforcing mode on
/usr/sbin/ntpdate, domain exists, learning mode on
/usr/sbin/openvpn, domain exists, learning mode on
* first whole running cycle took 9.89s
(press q to quit)

Javítottam, a 0.41-ben elérhető. Feltöltöttem. Akár PPA-ból is frissítheted. Változások itt.

Most már újra lehet kérni az átmeneti tanuló módot bármikor, úgy ahogy számítottál rá. Ekkor az előzőt befejezi (vagyis az ideiglenesen tanuló módba átkapcsolt domain-eket visszateszi kikényszerítőbe), majd indítja az új átmeneti tanuló módot.

Egy megjegyzés: tegnap vettem észre, hogy sajnos chroot-ból futtatott folyamatokra még nem lesz jó tomld automatikusan, de dolgozok rajta. Habár ha MAC-et használ valaki, gondolom ritka lesz a chroot használata, de folyamatban.

Sajnos pont a kiadás után veszem észre ezeket a dolgokat, de ez van.

Holnap tervezem megváltoztatni az átmeneti tanuló mód kérésének működését. Jelenleg úgy működik, hogy ha a már kikényszerítő módban lévő alkalmazás belefut egy hozzáférés megtagadásba, akkor ezt észreveszi a felhasználó. Ekkor kér ÁTM-ot, miután az alkalmazásnak még egyszer el kell követnie egy hozz. megtagadást, majd ekkor tomld a megtagadás bejegyzéseit engedélyezi és az alkalmazást is visszateszi tanuló módba. És ezek után, immáron harmadszorra nekifutva lesz csak minden megengedve igazán neki.

Ez így nem jó, kényelmetlen, és nem igazán jól használható. Úgy fogom átírni, hogy ha az alkalmazással gond volt, akkor a tanuló mód kérésére az ez előtt felhalmozódott (mínusz 5 perc vagy még kigondolom mi legmegfelelőbb) szabályokat engedélyezi tomld és egyből tanulóba teszi az összes domain-t ezek közül. Így 3 próbálkozás helyett az elsőre már a kívánt működést kapjuk.

Mivel az általános tanuló módnál a mostani verzióban sem tudjuk jósolni, hogy adott pillanatban milyen alkalmazás okoz hozz. megtagadást, ezért az általam kitalált megoldást sem tartom rosszabnak. Úgyis arról szól, hogy a rendszerünknek megbízhatónak kell lennie amíg létrejön az összes domain kikényszerítő módban.

Ha meg valaki kevésbé engedékeny akar lenni, akkor

sudo tomld -l

helyett kérhet tanuló módot csak bizonyos domain-eknek:

sudo tomld -l firefox

Remélem holnapra meglesz, zavar hogy ezt eddig nem láttam.

Kieg.: ha viszont ÁTM kérése előtt nem volt hozzáférés megtagadás, akkor úgy fog működni, mint eddig, vagyis a mostantól beérkező első csokor hozz. megtagadás domain-jei lesznek visszakapcsolva tanuló módba, és utána már más domain nem. És ezek után akár még egyszer lehet már klikkelni az ÁTM kérésére az előző lejártának (max 1 óra) megvárása nélkül, ha további általános engedélyeket akarunk adni.

Tehát a gyakorlatban úgy néz ki, hogy a user firefox-ozik, és mikor belefut egy megtagadásba, akkor klikk az ÁTM-re, és onnétól minden oké. Nem kell semmilyen további esemény bekövetkeztére várni. Ennyi.

Úgy döntöttem, hogy átmeneti tanuló mód kérésénél az előzőleg begyűlt összes hozzáférés megtagadást engedélyezni fogom az összes ehhez tartozó domain-nel.

Tegyük fel van egy szerverünk, letelepítjük tomld-t, az meg szépen gyűjtöget meg állítgat. Miután átkapcsolódtak domain-ek kikényszerítő módba és hozz. megtagadást generáltak, kapunk róla e-maileket.

Tehát telepítés után pár nap múlva ránézünk a szerverre, mail parancs, és egy rakás deny bejegyzés vár. Ekkor nem tudok rá okot, hogy miért ne az összes bejegyzést engedélyezzem. Ha a rendszer kompromittált, akkor úgyis mindegy (a szabályokból pedig ez úgyis kiderülhet). A koncepció szigorúan az, hogy a tanulás alatt védtelen a rendszer. Ha már minden kikényszerítő módban van és nem generálódnak hozzáférés megtagadások (vagy igen, csak direkt nem akarjuk engedni), akkor onnétól elketyeghet ezzel a beállítással évekig imho.

Tehát a felhasználó szempontjából a legkényelmesebb megoldást fogom választani, és egy klikkre mindig minden addigi "probléma" meg fog oldódni ;)

(ez persze az aznapira fog vonatkozni a log rotate miatt)

Kicsit tovább gondoltam a dolgot.

Fontos szempontnak tartom a felhasználónak okozott bizonytalanság kikerülését a biztonság szem előtt tartása mellet is. Az eddigi működés alapján tomld várt, amíg egy alkalmazás hozz. megtagadást okoz, és ehhez engedélyezett ÁTM-ot max 1 órára. Ez nem jó, mert nem lehetünk biztosak benne, hogy nem az általunk várt alkalmazás okoz hozz. megt.-t, hanem éppen közben egy másik, és akkor az kapna tanuló módot. Erről ráadásul visszajelzés sincs. Tehát bármi történhet a háttérben.

A fentebb leírt megoldásom első fele szerintem jó, mikor is az általunk mailben már látott (vagy a logokban látott) hozz. megtagadásokat adnám csak hozzá utólag a policy-hez és csak ezek domain-jeinek adnék tanuló módot a jelentől számított max 1 órára (azért max, mert ha magától előbb visszavált kikényszerítőbe a domain, akkor előbb következik be a tanuló fázisának vége).

A változtatásom az lenne a továbbiakban, hogy csak ezt valósítanám meg. Tehát ha nem keletkezik előzőleg hozz. megtagadás, akkor semmit nem kapcsolok vissza tanuló módba. Ez 3 dolog miatt lenne a legjobb megoldás:

1) Előzőleg a log-okban vagy mailben látható exact infó alapján tudunk számítani meghatározható eseményre - nem pedig egy még nem bekövetkezett dologra számítanánk, amelynek nagy esélye van nem várható kimenetet produkálni

2) Nem lenne az, mint eddig, hogy 1 órára várakozik tomld egy megtagadásra, és akkor ez kap tanuló módot - ezt viszont nem látjuk működés közben, illetve csak később tudunk erről tudomást szerezni a log-okból, miután már megtörtént

3) Olyan domain-t úgysem akarunk visszakapcsolni tanuló módba, amely nem okozott hozzáférés megtagadást - főleg olyat, amelyet még nem is láttunk és nem tudjuk mihez férne hozzá - ha meg okoz hozzáférés megtagadást, az három helyen is látszik: mail, log, notification - tehát tudunk biztonságosan utána dönteni erről

Ezek miatt a bizonytalanság teljesen megszűnne és a kontrol maximális lenne. Ezt fogom leimplementálni.

Ez tehát a gyakorlatban így nézne ki:

- a felhasználó megtagadásba fut (pl. Firefox nem tudja elmenteni az oldalt, vagy egy betűtípust betölteni - erről FF is ad hibát, meg a fentebb említett 3 helyen is megjelenik erről a hozzáférés megtagadás bejegyzése).
- ekkor a felhasználó ráklikkel az ÁTM ikonra, ezzel az eddig hozz. megtagadást produkáló alkalmazások kapnak tanuló módot (jelen esetben csak FF), vagyis a megtagadás szabályként bekerül a FF szabályaihoz - vagyis ha csak ez okozott problémát, akkor már azonnal engedélyezve van "reptében", ha meg ennél megállt, de további hozzáférésre lesz szüksége, akkor azonnal megteheti, mert szintén "reptében" kapcsolom át tanuló módba - tehát semmilyen további eseményre nem kell várni a felhasználónak a probléma megoldásának azonnali elkezdéséhez

Ennyi.

Pontosan. A tanuló mód az összes előzőleg megtagadást produkáló alkalmazásra fog vonatkozni, de csak ezekre.

Tehát ha be lett kapcsolva a tanuló mód, és az általad vázolt esetben FF és TB is vissza lett kapcsolva tanuló módba, akkor hiába keletkezik hozzáférés megtagadás most, nem lesz vissza kapcsolva több domain. Mégpedig azért, mert így meg tudod tekinteni a deny logban vagy a mailben (vagy látod a notification-ben), hogy ha megint rányomsz az ÁTM-ra, akkor most mik fognak tanuló módot kapni. Tehát van kontrol, semmi nem bizonytalan. De persze ez nem gátol meg abban, hogy többször rányomj és mindennek megadd mindig a tanuló módot, mondván nem érdekel, csak legyen meg minden szabály minden domain-hez mielőbb, és majd csak ezután fogod fenntartással kezelni a jövőben ezt a lehetőséget, nyilván biztonsági okokból.

Legegyszerűbben böngészővel szoktam tesztelni, pl. egy egyszerű oldal elmentésével egy olyan mappába, ahova nem írna egyébként (nálam ~/Desktop/random/), vagy még jobb, a mentés ablakban a /tmp mappán belül mappa létrehozása is elég. Ez ártalmatlan a későbbiekben is szerintem.

Közben a wine-nal is belefutottam.

Kérdés, mi az amit alapul vesz a progi amikor visszamenőleg keresi a hozz.megtagadásokat?
Mi van akkor ha a progi többször próbálkozik ugyanazzal, és több ugyanolyan hozz.megtagadást produkál? Azok mind egyesével bekerülnek a policy-ba, vagy csak az eltérők?

/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011
/usr/bin/qlandkartegt allow_read /usr/share/mime/text/plain.xml add rules? (y) at Tue Aug 30 15:41:29 2011

0.44 - még nincs logrotate.d fájl :(

Lehet, jó lenne minden log sor elejére egy timestamp :-o

Egyszer vágtam át ÁTM-be,


/usr/bin/wine-preloader allow_ioctl /home/xxx/.wine/drive_c/ 0x82187201 add rules? (y) at Wed Aug 31 16:34:17 2011
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java allow_unlink /home/xxx/gvt7015941226951684737.gvt add rules? (y) at Wed Aug 31 16:34:17 2011
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java, switch to learning mode
/usr/bin/wine-preloader, switch to learning mode
* switch domains with new rules to learning mode

kis idő múlva panaszkodott, hogy


* warning: running cycles take too long
* directory with most files is: /usr/lib/python2.7/encodings/

eddig OK. De kb. 1 perc elteltével ismét azt írja:


* warning: running cycles take too long
* directory with most files is: /usr/lib/python2.7/encodings/

Mondjuk azóta csönd van :-D

Ok, végig gondolom hogy lenne a legjobb odanyomni minden bejegyzéshez az időpontot. A legátláthatóbb az lenne, ha a sor elején lenne, csak alapból nem így terveztem, meg spórolni akartam a hellyel is, ha pl. 80 karakteres terminálon kell bűvészkedni. Na, majd valamit kitalálok, de hasznos az észrevétel.

A warning üzenet nem jelent problémát, csupán annyit, hogy egyszer valamiért tovább tartott 1 ciklus mint 30 sec. A mappát pedig azért printelem ki, hogy meglegyen a lehetőség a gyorsításra úgy, hogy a rekurzívak közé tesszük.

Az alapértelmezett idő egységekkel még lehet majd játszani, azért 30 sec-re tettem ezt, mert i ciklus is 30 másodpercenként fut, tehát azt jelenti összességében, hogy a két ciklus között nem tudott befejezni egyet. Akár 60-ra is át lehetne majd állítani, de ez csak információs jellegű.

Szerk.: egyébként a kb. 15000 szabály (fentebbi bejegyzésed) az nagyon nem kevés :) És valószínű mindig meg fogod kapni ezt a bejegyzést, ha változás van a szabályok között (pl új jön be), mert ennyi szabálynál nem végez 30 sec-en belül. A check() ciklusom csak akkor fut le, ha változik a domain policy. De ennek a log-nak a jelenléte nem gondolom hogy zavaró.

megnéztem most a policy fájlt, és ilyenek sorjáznak benne tömegével:

allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13082/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13100/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13125/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13162/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13165/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13166/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13187/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13190/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13192/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13193/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13197/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13200/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13201/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13205/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13229/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13242/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13243/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13269/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13290/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13301/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13316/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13339/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13357/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13364/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13373/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13387/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-05/13392/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13408/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13412/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13430/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13434/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13435/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13437/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13442/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13446/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13458/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13491/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13495/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13499/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13506/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13517/\*
allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/2008-06/13518/\*

és a sor folytatódik, régi bejegyzések. A Tuhu-n térképészkedek és a könyvtárak végén a feltöltött track-ek vannak.
Ezeknek nem kellene összeugrani ilyenre:

allow_read /home/\*/.wine/drive_c/Program\040Files/mapedit/godollo/upload/\{\*\}/ vagy hasonlóra? Mondjuk elég specifikus, be tudom tenni rekurzívba, ha úgy gondolod a logika szerint, hogy az ilyen mintát nem szabad összefogni...

"Ezeknek nem kellene összeugrani ilyenre?..."

Nem. A path összevonásom csak random nevű vagy csak számból álló almappa bejegyzésekre vonatkozik, és azok közül is a legalább 6 karakter szélesekre.

Lásd lentebbi bejegyzésem (--info kimenetből lehet dönteni, hogy mit tegyünk be a rekurzív tag alá).

Hosszú távon érdemes lenne ezt kicsit átdolgozni szerintem, mert biztos vagyok benne, hogy elég sok esetben nem fog a tomld rájönni, hogy a random adat az tényleg random. Én azt csinálnám (nem tudom, mennyire megvalósítható, meg mennyire biztonságos), hogy a kigyűjtött szabályokat egymással hasonlítanám össze, és ha a különbség mindig a string egy kis részére korlátozódik, akkor az mehet rekurzívnak.

--
Don't be an Ubuntard!

"..hogy a kigyűjtött szabályokat egymással hasonlítanám össze, és ha a különbség mindig a string egy kis részére korlátozódik, akkor az mehet rekurzívnak.."

Ezt csinálom :)

Csak nem rekurzívnak teszem be, hanem sima wildcard az alkönyvtár helyére. Ennek ott van szerepe, hogy el tudok képzelni olyan helyzetet, hogy nem akarna egy folyamat hozzáférni rekurzívan az eglsz véletlen nevű részt tartalmazó mappa alatt mindenhez, hanem csak az adott mappához.

De egyébként azért úgy írtam meg az elérési útban véletlen részt felismerő függvényemet, hogy kisebb részre illeszkedjék, mert így nagyobb az esélye, hogy tényleg random mappa. Mégpedig azért, mert ha nem illeszkedik, akkor úgyis jön új - éppen a random volta miatt - ez pedig a tanuló idő alatt nem gond.

"Csak nem rekurzívnak teszem be, hanem sima wildcard az alkönyvtár helyére."

Úgy gondoltam, csak nem úgy írtam. :)

"Mégpedig azért, mert ha nem illeszkedik, akkor úgyis jön új - éppen a random volta miatt - ez pedig a tanuló idő alatt nem gond."

Akkor a tanuló mód végéig rá fog jönni, hogy az elérési út random részt tartalmaz?

--
Don't be an Ubuntard!

Elég nagy az esélye.

Úgy gondolom, hogy a megvalósított automatizmus megfelelő, és az utólagos tanuló mód kérésének lehetősége kiegészíti a nehezn megvalósítható részeket, mindezt az ellenőrizhetőség megtartásával.

Egyébként ez volt az egyik legnehezebb rész (meg amit leggyorsabban megírtam időben ;), vagyis hogy az állandóan visszatérő random részt wildcrad-al helyettesítsem valahogy. Sok tesztelés hiányzik még, mert ahogy itt is látszik, sok alap dolog elkerüli az ember figyelmét, csak az miatt, mert nem nincs időm rendes napi használatnak kitenni az adott funkciót.

Átlagosan 116 bejegyzés 1 domain-hez :-o

grep -c home /etc/tomoyo/domain_policy.conf
3518

grep -c \/usr\/ /etc/tomoyo/domain_policy.conf
10796

grep -c \/usr\/lib /etc/tomoyo/domain_policy.conf
9167

grep -c python /etc/tomoyo/domain_policy.conf
5119

grep -c python2.7 /etc/tomoyo/domain_policy.conf
4846

grep -c \/lib\/python /etc/tomoyo/domain_policy.conf
3223

grep -c \/lib\/python2.7 /etc/tomoyo/domain_policy.conf
3018

find /usr/lib/python2.7/|wc -l
5888

Ilyenek vannak a logban:

/usr/lib/firefox-6.0/firefox-bin (deleted), no domain, create domain with learning mode
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted), no domain, create domain with learning mode (restart needed)

ez a deleted , no domain, create domain normális?

Ez olyankor fordulhat elő, ha a kernel memóriában létezik a domain, de a bináris az elérési útján hiányzik.

Nem frissítettél, amelynél megváltozott az elérési út? pl. firefox-6.0 helyett 6.1 például?

Amúgy nemsokára jelentkezek egy új verzióval, majd bővebben leírom.

Látom most frissíült a FF is, és az elérési útja változott erről:

/usr/lib/firefox-0.6/firefox-bin

erre:

/usr/lib/firefox-0.6.1/firefox-bin

Egyébként reboot után teljesen eltűnik, viszont az nélkül sem kellene megjelennie. Ezt tesztelni fogom. Egy apró kozmetikai bug miatt pedig még egy tomld verziót frissítenem kell nemsokára.

Közben kiadtam a 0.48-at.

Tovább fejlesztettem az --info paraméterre adott kimenetet, itt már látható több mélységben a top könyvtárak nevei, amelyek a legtöbb bejegyzést tartalmazzák. Ezek közül opcionálisan betehetők egyesek a [recursive] tag alá a tomld.conf-ba. Nyilván ilyet mint "/usr/lib" nem kellene, hanme inkább /home mappán belüli mélyebb eléréseket, de csak ha ennyire sok szabály van.

(PPA is mindjárt legenerálódik perceken belül).

a tomld -i -ben van ilyen:

(100_%) /usr/lib/firefox-5.0/firefox-bin
(100_%) /usr/lib/thunderbird-5.0/thunderbird-bin

ezek már nem létező domainek....

Igen.

Ezt végig kell gondolni, hogy pl. minden indításkor törölje azokat a domain-eket, amelyeknek hiányzik a binárisa, vagy időről időre?

Az is kérdés, hogy töröljük-e? Az idővel összegyűjtött szabály van-e olyan értéktelen, hogy mindig kidobjuk? Előfordulhat olyan, hogy kellene még újra valamikor?

Szerk.: meg ne felejtsük el, hogy a tanuló fázis igényel erőforrást leginkább, miután minden domain végleges lett, akkor már csak a kernel Tomoyo része dolgozik, amely elhanyagolható.

Teljes automatizációt szeretnék, tehát szeretném elkerülni az újabb paraméter kapcsolók létrehozását.

Ezt nem tartom jónak, mert ezt az időt abszolút nem lehet megbecsülni.

Úgy fogom inkább csinálni, hogy törlöm minden tomld induláskor a hiányzó binárisok domain-jét, viszont nyomok neki egy backup-ot minden ilyen művelet előtt. Így a lemezen archívként mindig minden megmarad. Egyet értesz?

És ha megjelenik a bináris akkor backup-ból visszatolni a szabályokat?

Egyébként jó ötletnek tartom, ha nincs bináris, kidobni a cuccot, és ha kell tanulja újra...

Mondjuk mi van akkor, ha egy galád prg. letörli a binárist, a tomld észreveszi, kidobja a szabályokat, a progi feltesz egy kompromittált binárist, aki vígan élvezi a tomld learn opcióját?

Ha egy folyamat tud binárist törölni, akkor eleve tanuló mód idő alatt már kompromittált a rendszer, tehát értelmét veszti minden további biztonsági resztrikció. Meg eleve root joggal kellene futnia, ahol pedig már adhat magának jogot szabály változtatáshoz is manager.con-on keresztül.

Viszont biztonsági szempontból kicsit aggasztó a gondolat, hogy a szabály rendszer olyan drasztikusan változhatna, hogy egy komplett domain-t törlünk, csak azért, mert egy fájl hiányzik (amely számtalan dolog miatt előfordulhat).

Viszont a sok felesleges szabály is nagyon megnöveli a futás időt.

Erre még aludni kell egyet :)

De mindettől függetlenül, a tomld kimenetében nem szabadott volna meglenni a "(deleted)" taggal ellátott domain-ek nevének, mert már a load() rutinomban eltávolítom ezeket.

Be tudnád esetleg másolni azt a részt a log-ból, ahol ez látszik?


started at Thu Sep 1 08:52:24 2011
tomld (tomoyo learning daemon) 0.47
Linux version 2.6.38-11-generic-pae (buildd@rothera) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #48-Ubuntu SMP Fri Jul 29 20:51:21 UTC 2011
* mail requested but binary /usr/sbin/sendmail missing
* encrypted fs found
* recursive directories set:
/home/\*/fejlesztes/sajat/eclipse/.metadata/.plugins/
/home/.ecryptfs/szimszon/.Private/
* exception domains
/bin/bash /bin/dash /bin/rbash /bin/sh /sbin/init /usr/bin/screen /usr/sbin/sshd /usr/sbin/tomld /usr/sbin/tomoyo-loadpolicy
* new processes using network
/usr/sbin/avahi-daemon
/usr/sbin/cupsd
/usr/bin/pidgin
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted)
/usr/lib/firefox-6.0/firefox-bin (deleted)
/usr/bin/ssh
* already existing main domains
avahi-daemon cupsd pidgin ssh
* checking policy and rules
/home/szimszon/prg/eclipse/eclipse, domain exists, learning mode on
/sbin/dhclient, domain exists, learning mode on
/usr/bin/gnome-open, domain exists, learning mode on
/usr/bin/gpg, domain exists, learning mode on
/usr/bin/host, domain exists, learning mode on
/usr/bin/pidgin, domain exists, enforcing mode on
/usr/bin/python2.7, domain exists, enforcing mode on
/usr/bin/qlandkartegt, domain exists, enforcing mode on
/usr/bin/rdesktop, domain exists, enforcing mode on
/usr/bin/skype, domain exists, enforcing mode on
/usr/bin/ssh, domain exists, enforcing mode on
/usr/bin/transmission-gtk, domain exists, learning mode on
/usr/bin/wine-preloader, domain exists, enforcing mode on
/usr/bin/wineserver, domain exists, learning mode on
/usr/lib/apt/methods/http, domain exists, enforcing mode on
/usr/lib/cups/backend/ipp, domain exists, learning mode on
/usr/lib/firefox-5.0/firefox-bin, domain exists, learning mode on
/usr/lib/firefox-6.0/firefox-bin, domain exists, learning mode on
/usr/lib/firefox-6.0/firefox-bin (deleted), no domain, create domain with learning mode (restart needed)
/usr/lib/gvfs/gvfsd-http, domain exists, enforcing mode on
/usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java, domain exists, enforcing mode on
/usr/lib/network-manager-openvpn/nm-openvpn-service, domain exists, learning mode on
/usr/lib/thunderbird-5.0/thunderbird-bin, domain exists, learning mode on
/usr/lib/thunderbird-6.0/thunderbird-bin, domain exists, learning mode on
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted), no domain, create domain with learning mode (restart needed)
/usr/sbin/avahi-daemon, domain exists, enforcing mode on
/usr/sbin/cupsd, domain exists, enforcing mode on
/usr/sbin/ntpdate, domain exists, learning mode on
/usr/sbin/openvpn, domain exists, learning mode on
* warning: running cycles take too long
* directory with most files is: /usr/lib/python2.7/encodings/
* first whole running cycle took 40.83s
(press q to quit)
/usr/lib/firefox-6.0/firefox-bin (deleted), no domain, create domain with learning mode (restart needed)
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted), no domain, create domain with learning mode (restart needed)
* warning: running cycles take too long
* directory with most files is: /usr/lib/python2.7/encodings/
/usr/lib/firefox-6.0/firefox-bin (deleted), no domain, create domain with learning mode (restart needed)
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted), no domain, create domain with learning mode (restart needed)
* warning: running cycles take too long
* directory with most files is: /usr/lib/python2.7/encodings/
/usr/lib/firefox-6.0/firefox-bin (deleted), no domain, create domain with learning mode (restart needed)
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted), no domain, create domain with learning mode (restart needed)
* warning: running cycles take too long
* directory with most files is: /usr/lib/python2.7/encodings/
/usr/lib/firefox-6.0/firefox-bin (deleted), no domain, create domain with learning mode (restart needed)
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted), no domain, create domain with learning mode (restart needed)
* warning: running cycles take too long
* directory with most files is: /usr/lib/python2.7/encodings/
/usr/lib/firefox-6.0/firefox-bin (deleted), no domain, create domain with learning mode (restart needed)
/usr/lib/thunderbird-6.0/thunderbird-bin (deleted), no domain, create domain with learning mode (restart needed)

Köszi, meg is van a hiba.

Ez a rész után * new processes using network már megjelenik a bináris a deleted cimkével. Az van szerintem, hogy Tomoyo a kernelben lecseréli az összes ilyen bináris útvonalát (deleted) cimkésre, és így a /proc fájlrendszerben is átneveződik. Ennél a résznél azokat a folyamatokat gyűjtöm össze, amelyeknek van megnyitott hálózati socket-jük. Viszont a réginek még nem timeout-olt és aktív marad egy ideig, de a neve megvátolzik Tomoyo miatt, tehát új domain-ként értelmezi tomld.

Javítani fogom és nagyon köszi!

Tudtam is reprodukálni. Töröltem /usr/sbin/cupsd-t a VM rendszeremben, és azonnal (deleted) jelöléssel hozta új domain-ként.

Érdekes egyébként, hogy a kernel (és azon belül Tomoyo) nyomon követi a binárist az átnevezéskor. Tehát ha /usr/sbin/cupsd-t átneveztem először .bak végződéssel, akkor nem történt semmi, ezt vette alapul a régi domain elérési útvonalának. Ez meglepett.

Ezt úgy csinálta meg Tomoyo, hogy automatikusan létrehozott egy cups.bak domain-t a kernelben lévő domain_policy-n belül. Így amikor tomld betöltötte, akkor ott volt már cupsd.bak is, szépen ugyanazokkal a szabályokkal és profillal feltöltve mint a cupsd előtte.