tomld 0.38 (megjegyzések)

Nemrég kiadtam és megjelent az első teljesnek tartott verzióm. Ehhez szeretnék írni néhány gondolatot.

Ha valaki szerverre telepíti, akkor az /etc/tomld/tomld.conf fájlba betehet e-mail értesítést, pl. a helyi root-nak és egy külső címre: 

[mail]
root
someone@somewhere.org

Itt a mailer binárist fix-en tárolom a kódban biztonsági okokból: /usr/sbin/sendmail
Ha valakinek más útvonal kell, akkor fordítsa le azzal a beállítással, itt az idevonatkozó kódrészlet: 

char *mail_mta  = "/usr/sbin/sendmail";

Ha kicsit áttekinthetőbb kimenetet szeretnénk, akkor leállítható a szolgáltatás, és manuálisan elindítható -c kapcsolóval, így a terminálba megy az output színesben: 

sudo service tomld stop
sudo tomld -c

Ha teszteléshez valaki át akar mindent kapcsolni kikényszerítő módba egy idő után, akkor a -m kapcsolóval indítva tomld-t, majd kilépve belőle az össze már tanuló módú domain átkapcsolódik kikényszerítő módba, másodszorra futtatva -m kapcsolóval, majd kilépve pedig az előző futás alatt létrejött domain-ek is. Visszakapcsolni mindent a --learn-all kapcsolóval lehet.

Itt fontos megjegyezni, hogy a --learn-all kapcsoló lenullázza az eddig összegyűjtött CPU időt, és a tanulási mód nulláról kezdődik újra.

A FAQ dokumentációt bővítettem a csomag parancssoros telepítésével, bár biztos egyértelmű mindenkinek, kezdőknek beírom ide: 

sudo dpkg -i tomld*.deb; sudo apt-get -f install

Egy másik fontos dolog: Az összes Debian és Ubuntu verzió közül a stabil kiadástól felfelé egyedül a Debian 6-os (Squeeze) tartalmaz gyári 2.6.32-es kernelt, a többi mind ennél magasabb verziójút. Ez azért érdekes, mert 33-astól felfelé Tomoyo tartalmaz egy speciális wildcard-ot, amelyet rekurzív wildcardként lehet használni, és ezt használom is tomld-ben. Ezért ha pl. egy Samba megosztás is kikényszerítő módba kerül végezetül, akkor ott a mappán belüli átnevezések másik mappába nem igazán tudnak működni, mert a 33-as kernel alatt én legenerálom az összes almappára a wildcard-ot, pl: 

allow_rename /srv/samba/\* /srv/samba/\*
allow_rename /srv/samba/\*/\* /srv/samba/\*/\*
allow_rename /srv/samba/\*/\*/\* /srv/samba/\*/\*/*

Ennek a négyzete lenne, ha minden egyes mélységhez minden mélységet generálnék. Ezt nem teszem, úgyis már csak az egyedüli Debian 6-os érintett a rekurzív wildcard hiányában. Ez van, újabb kerneleknél az átnevezés már nem gond. Ehhez egyébként a tomld.conf-ba betehetjük pl.: 

[recursive]
/srv/samba/

Van néhány olyan megoldás a kódban, amely a kis elem számra való tekintettel nem hatékony, de nem is időkritikus itt. Pl. több listát sima text formában tárolok futás időben newline karakterrel elválasztva soronként, és így is rendezem, stb. Ezt lehet hogy még átvariálom később, de 5-50 db-os a lista helyenként.

Kis érdekesség: kb. 34 ezer sornyi kódot toltam bele, és ebből kidobtam 22 ezret. Ezt nem tartom jó aránynak. Igaz ebből 10 ezer volt a python kód, tehát -10 az, amit teljesen újraírtam.

Az első elképzeléseimhez képest sokkal több problémába futottam bele. Ilyen volt pl. hogy nem akartam tárolni futás időben adatbázist vagy egyéb módon infót az aktuális domain-ekről és állapotaikról. Végül ezt úgy oldottam meg, hogy a szabályok közé illesztettem saját kódot, úgymint:

allow_read /tomld/43753765436563465(itt egy hash kód áll)/create_time/436545536(epoch time)

..és hasonló. Így a policy-t elmentve megmarad mind fájlban, illetve futás időben kernel memóriában is az infó külön domain-enként, mindez anélkül, hogy állandóan disk-hez kellene nyúlnom. Ennek kiküszöbölése fontos volt számomra, hogy leredukáljam a load-ot.

Jelenleg a daemon 2 másodpercenként nézi, hogy létrejött-e új TCP vagy UDP socket, és ha igen, akkor létrehozza a domain-t az adott folyamathoz. De ezt csak a második ciklusban látjuk print-elve, amely 30 sec-enként fut le. Ez a két idő érték vitte le az átlag CPU felhasználását a folyamatnak 1-3 %-ra. Ez szerintem elfogadható, még ha akkus notebook-ról is van szó szerintem.

Ha használat alatt egy domain korán kerülne kikényszerítő módba kapcsolásra, akkor valószínűleg hozzáférés megtagadást tapasztalhatunk az adott szoftverrel kapcsolatban (pl. böngészőből nem tudunk lementeni fájlt vagy mappát létrehozni stb.). Ekkor kérjünk ideiglenes tanuló módot így (rövidebben -l kapcsoló):

 sudo tomld --learn

Ekkor csak a most létrejött hozzáférés megtagadást okozó domain-ek kerülnek visszakapcsolásra tanuló módba, és ezért érdemes bezárni és újra indítani az alkalmazást a parancs kiadása után. Ha bejött az első hozzáférés megtagadás, vagy együtt az összes, akkor az ideiglenes tanuló mód kérvénye azonnal érvényét veszti. Pont azért, hogy csak azt a domain-t engedélyezzük, amellyel probléma van, és ne az összeset.

Ezzel így a többi kikényszerítő módban futó "biztonságos" domain továbbra is kényszerítő módban marad és nem befolyásolja azokat a fenti művelet.

A CPU spórolást több módon próbáltam elérni. Pl. rekurzív kérésnél minden mappának meg kell néznem a mélységét. Ezt letárolom egy tömbbe ha még nem tettem volna meg, tehát ennek vizsgálata program indításonként csak egyszer fut le. Illetve a syslog-ot is csak akkor vizsgálom, ha változott a módosítás dátuma. Amíg pedig nem jöb új szabály, nem futtatom a teljes check() ciklust, amely a legidőigényesebb.

Frissítés: közben hozzáadtam a kódhoz azt a lehetőséget, hogy a tomld.conf bejegyzésben az [exe] tag alatti program nevekkel extra domain-eket kérjünk ezekhez. Pl.:

[exe]
vlc