Ugye mivel egy alkalmazás által létrehozott fájlról nem teljességgel dönthető el hogy átmeneti-e, vagy visszatérően ugyanazon a néven meg lesz sokáig, ezért az alap ötletem az volt, hogy fájlok helyett mappákra állítok be szabályokat. Vagyis a mappa végét (vagy annak végén lévő fájlt) csillagozom ki.
A gond a random fájlokkal az, hogy így a szabály rendszer folyamatosan hízik, és így olyan fájlokra van mindig hivatkozás, amiről még nincs szabály, tehát folyamatos a hozzáférés megtagadás.
Persze kézzel könnyű szabályt létrehozni, az ember ránézésre látja hogy melyik fájl tartalmaz random részt, de adott esetben 3-4 ezer szabályt kézzel toszogatni folyamatosan (akár minden rendszer frissítéskor vagy egyéb más rendszer változáskor is) sok idő és a hiba lehetőség is nagy és nehezen látható be. Ezt alapból nagy hiányosságának tartom az általam ismert MAC rendszereknek. A kézzel állítgatott nagy számú szabályok miatt a komplexitási szint egy idő után túl nagy és nem triviális a helyes működés (szerintem).
Ettől függetlenül létrehoztam egy olyan részt, amely megpróbálja kitalálni a random voltát a fájloknak, vagyis nem azt hogy random-e, hanem adott feltételek esetén kicsillagozásra kerül az olyan mappákban is, amelyek a kivételek közt szerepelnek alapból.
Például chromium böngésző is hoz létre $HOME-ba random temp fájlt ".org.chromium.CP5la6" formában.
--
A teljes biztonságot nyilván az összes szabály összességében határozza meg. Az egész sajtból minden engedély és minden egyes wildcard lecsíp egy kicsit, és a végén ami marad, azt vehetjük a biztonsági szint maximumának.
Az 1 hónapos intenzív fejlesztés során több strukturális bővítést is végeztem, amelyre szükség volt de eredetileg nem volt látható, és úgy gondolom, hogy a jelenlegi működéssel egész jó szabály rendszert kapunk.
A teljes flow chart megtalálható a forrás legelején, amelyet kibővítettem a szabály átdolgozásos résszel is részletesen.
--
Remélem hogy nem nagyon lesz durva hiba a logikámban, és egy használható eszközöm marad, amelyet szeretnék minél kényelmesebbre és automatikusabbra alakítani.
--
(Talán) érdekességként bemásolom ide az exim4-em kialakított konfigját.
Itt az alábbi látható:
- < kernel > rész után áll közvetlenül a bináris az elérési úttal, ez azt mutatja hogy saját domain-ben van, vagyis mindegy melyik más folyamat indítja az exim-et, mindig ez a szabály rész fog vonatkozni rá (alapból minden egyes általam létrehozott domain-t így állítok be)
- use_profile 3 azt jelenti, hogy kikényszerítő módban van (0 = kikapcsolt, 1 = tanuló, 2 = engedékeny (nem hoz létre szabályt és engedi a hozzáférést, de beírja a log-ba a hozzáférésről a megtagadást), illetve 3 = kikényszerítő mód)
- a többi rész magáért beszél - a progimmal a lib-ek verzióit is átpofozom és wildcard-ra cserélem, amely imho megengedhető a biztonság - használhatóság arányt figyelembe véve, és verzió váltáskor kevesebb problémát szül
Úgy gondolom ezzel elég jól bezárható a folyamat, és bizonyára nincs teljes biztonság soha, de a semminél sokkal több.
< kernel > /usr/sbin/exim4
use_profile 3
allow_create /var/run/exim4/\*
allow_execute /usr/sbin/exim4
allow_read /etc/group
allow_read /etc/ld.so.cache
allow_read /etc/localtime
allow_read /etc/nsswitch.conf
allow_read /etc/passwd
allow_read /etc/services
allow_read /lib/libc-\*.so
allow_read /lib/libcrypt-\*.so
allow_read /lib/libdl-\*.so
allow_read /lib/libm-\*.so
allow_read /lib/libnsl-\*.so
allow_read /lib/libnss_compat-\*.so
allow_read /lib/libnss_files-\*.so
allow_read /lib/libnss_nis-\*.so
allow_read /lib/libpcre.so.\*
allow_read /lib/libpthread-\*.so
allow_read /lib/libresolv-\*.so
allow_read /proc/sys/kernel/ngroups_max
allow_read /usr/lib/libdb-\*.so
allow_read /usr/lib/libgcrypt.so.\*
allow_read /usr/lib/libgnutls.so.\*
allow_read /usr/lib/libgpg-error.so.\*
allow_read /usr/lib/libtasn\*.so.\*
allow_read /usr/lib/libz.so.\*
allow_read /var/lib/exim4/config.autogenerated
allow_read /var/lib/exim4/config.autogenerated.tmp
allow_read/write /dev/null
allow_read/write /var/run/exim4/\*
allow_truncate /var/run/exim4/\*
allow_unlink /var/run/exim4/\*
allow_write /var/log/exim4/mainlog
- log69 blogja
- A hozzászóláshoz be kell jelentkezni
- 873 megtekintés
Hozzászólások
Van valami mérés arról, hogy milyen teljesítményromlást jelent a használata?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
A hivatalos Tomoyo faq szerint elhanyagolható.
- A hozzászóláshoz be kell jelentkezni
Amúgy szerintem érdemes lenne a segédprogramodból néhány csomagot készíteni, és egy kis hírverést csapni neki. Én ezt egy ígéretes projectnek tartom, nem tartom kizártnak, hogy a közeljövőben a disztribúciókba is belekerüljön, ami aztán hozná a további hírverést. Esetleg ha néhány embert megkeresel a disztribeknél, az segíthet.
Mindenesetre hajrá, sok sikert! :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
kösz. feldobtam az ubuntu-hardened és a debian-security listán is (elvégre csak ezek a támogatottak jelenleg). egyelőre a tomoyo listáról jött visszajelzés.
amit igazából szeretnék vagy gondolkodok rajt, az egy olyan okosabb daemon, amit esetleg boot folyamat során is indíthatnánk. és tegye a dolgát, ne kelljen semmi user input a rendszer bekeményedéséhez. ha meg úgy gondolja, akkor lépjen ki. (tomld futás közben valszeg nem igen biztonságos a rendszer a sok szoftver réteg és python miatt, tehát az elv az, hogy beállítani a rendszert ezzel amíg megbízhatónak tarjuk a környezetet, és kész, utána ne futtassuk).
tehát pl. döntse el, mikor érkezik el az optimális idő, hogy adott folyamatot átkapcsoljon tanuló módból kikényszerítőbe, távolítsa el a nem használt domain-eket (a feldolgozáshoz erőforrást vesz el a felesleges munka), meg egyéb ezzel kapcsolatos felmerülő helyzeteket oldjon meg. de mindenképpen az automatizmus szem előtt tartásával. annak nincs értelme hogy belefejlesszek ezer kapcsolót, aztán a user majd játszadozzon el, meg tanulja meg használni. egyszerűség és automatizmus a cél, meg az hogy a semminél nagyob security. ennek látom értelmét.
- A hozzászóláshoz be kell jelentkezni
Teljesen jók a meglátásaid, egy virtuális gépben mindenképpen ki szeretném próbálni és visszajelzek. :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
a tesztelés nagyon nagy segítség lenne, mert nagyon sok regexp-et használok, sok a text manipuláció, és magam is találtam sok hibát már.
ha teszteled, akkor egyik része egyszerű: miközben használod és akár tanuló akár más módban vannak a domain-ek, manuálisan kellene ellenőrzni az /etc/tomoyo/domain-policy.conf fájlban a szabályokat, hogy jók-e az általánosítások, amiket a progi végez. volt olyan hogy allow_mkdir -ben a path végéről lemaradt a / jel, meg hasonlók. jó lenne az ilyen apró bug-okat kitisztítani.
szerk.: ja még annyi, hogy egyszerű szolgáltatásokra nagyon hamar megtanulja a szükséges szabályokat - lévén nem sok helyre írnak. tehát kisebb progiknál (mint dnsmasq, exim meg hasonlók) nem kell napokig futtatni hogy gyűjtse a szabályokat. egy reboot a szolgáltatásnak, azt kész. lehet ellenőrizni, hogy a tomoyo által begyűjtött szabályokat mire cseréli ki tomld.
- A hozzászóláshoz be kell jelentkezni
(akár az oldalamon a jabber chat címemet is vedd fel nyugodtan ha olyan kérdés van, kösz)
- A hozzászóláshoz be kell jelentkezni