Az ehhez szükséges infrastruktúrára nincs ötletem egyelőre. Jó lenne ha a felhasználók könnyen hozzájárulhatnának a saját szabályaikkal, akár olyan domain-hez beküldve, ami még nem is létezik nálam.
(Github elég hatékony ehhez hosszú távon? Vagy van már kész erre megfelelőbb megoldás?)
Átvizsgálás után merge-elném a domain szabályokat az upstream-be.
Persze itt felmerül a kérdés az emberi hiba valószínűségének mértékéről. Ez olyan szempontból nem probléma, hogy azt a policy-t követem, hogy az automatikusan generált szabályhoz hozzá _sose_ adunk, csak maximum elveszünk, mégpedig az olyan bejegyzéseket, amelyek adott rendszerre vonatkoznak, és nem igazán általánosak. Ezért a szabály csak szigorodni tud, és a hiányzó láncszemeket majd adja hozzá mindenki tomld futtatásával, a többire elméletileg spórolt valamennyi időt.
Jelenleg tesztnek összedobtam egy rules mappát, ami így néz ki:
https://github.com/log69/tomld/tree/master/rules
.
├── README
├── rules
│ ├── debian-6-amd64-dhclient.txt
│ ├── debian-6-amd64-dig.txt
│ ├── debian-6-amd64-dnsmasq.txt
│ ├── debian-6-amd64-exim4.txt
│ ├── debian-6-amd64-host.txt
│ ├── debian-6-amd64-ssh.txt
│ ├── debian-6-amd64-whois.txt
│ └── debian-6-amd64-xtightvncviewer.txt
└── tomld.py
A rules mappába fő domain-enként tettem a fájlokat ilyen formában:
platform-version-arch-binaryname.txt
Mivel azért a legenerált szabályok jócskán függenek az adott rendszertől (milyen font-ok vannak telepítve milyem WM-mel, milyen DE stb.), ezért egyelőre csak a könnyen behatárolható domain-eket lenne érdemes karban tartanom. Sok folyamat megfelel ennek a kritériumnak, mivel a futtatásához a függőségeinek amúgy is telepítve kell lennie. Talán ez a mennyiség is valami.
Most tervezem implementálni tomld-be az automatikus letöltést adott domain-hez szabály generálás előtt, ha létezik. A megoldás még kialakítás alatt. Hash és digitális aláírást tervezek. Gondolkodok rajt hogy ez legyen-e az alapértelmezett, vagy kérni kelljen. Nem akarom túlvariálni sok kapcsolóval, de a cél is az lenne hogy a default beállítás legyen a legkényelmesebb, leghatékonyabb és legautomatább.
Szerk.: Mivel ezzel már netről húzna le kódot tomld, így felmerül az idegen kód injektálás lehetősége is, amit mérlegelnem kell. Kérdés hogy az ezzel spórolt idő vs. csak helyi kód futtatása alalpján melyik éri meg jobban?
Ha a szabályokat sikerült a távoli szerveren kompromittálni, akkor az már hibákat használhatna ki tomld-ben, ami biztos van dögivel, illetve magában Tomoyo-ban is.
- log69 blogja
- A hozzászóláshoz be kell jelentkezni
- 865 megtekintés
Hozzászólások
úgy döntöttem nem mozgatok meg töltök le semmit neten keresztül tomld futása közben, hanem megnézem hogy van-e rules mappa tomld.py mappájában. ha igen, akkor onnét vesz szabályokat ha van egyező process név, na nincs, akkor csak automatikus a szabály generálás.
így elég lesz a git clone a program és szabályok frissítésére is.
- A hozzászóláshoz be kell jelentkezni
esetleg apparmor profileok konvertalasa?
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
valamikor át akarom nézni alaposan, milyen access deny üzenetek vannak, hogy működik.
a MAC wiki szerint:
"AppArmor is not capable of restricting all programs"
ez egylőre nem tudom mit takar.
szerk.: jó lenne körvonalazva látnom, hogy érdemes-e akár selinux, akár apparmor irányban elgondolkodni. bár amit játszottam selinux-al, abból az valszeg nem lesz. vagy pedig az időt inkább egyre fordítani, és inkább újítani, mint kompatibilizálni? a tomoyo-s arcok csinálnak kernelt CentOS-hez, tehát gyakorlatilag fedora és opensuse a kakukktojás az ingyenes rendszerekből. a fizetősnél meg nyilván nem fognak 3rd party által forgatott kernel-t használni, amihez nincs support.
- A hozzászóláshoz be kell jelentkezni
Még azon is gondolkodok, hogy AKARI-val összelövöm a cuccot. Ugye ez maga a Tomoyo, csak éppen betölthető kernel modulként, és nem kell hozzá újra- vagy Tomoyo-val fordított kernel.
Itt egy jó összehasonlító táblázat:
http://akari.sourceforge.jp/comparison.html.en
Így a kernel modullal bármilyen Linux-on egyszerűen használható lenne. Valszeg az lesz ha odáig jutok és minden mainstream disztrón sikerül letesztelni, hogy az AKARI forrást összereszelem a disztrók aktuális stabil verziójának kernelével, és egy fordító script-et biztosítok hozzá. (úgy értem nem változtatok AKARI-n, csak forrás csomagot csinálnék a különböző rendszerekhez)
Vagyis azon a rendszeren, ahol nem támogatják a Tomoyo-t a gyári kernellel, ott annyi lenne, hogy a script futtatásával az leszedné az AKARI forrást, build-eli, majd kernel modul betölt. Utána meg 2x tomld futtatása, azt kész.
Úgy gondolom ezzel már egyszerű lenne a telepítés, főleg rendszergazdáknak.
Meg valszeg azt rosszul tettem, hogy tomld-be beleépítettem a hiányzó csomag telepítést. Ezt lehet külön veszem. A Tomoyo beüzemelésnek lehet csinálok egy külön script-et, ez megnézi hogy milyen csomag kell vagy mi egyebet csináljon, hogy meglegyen a támogatás.
Mindenképpen "egy klikkes" automatikus megoldást akarok az egész problémára. 1) Tomoyo támogatás 2) Szabályok beállítása
Most gyorsan megcsinálom jövő héten a helyi mappából szabályokkal való gyorsítását a folyamatnak (ez lényeges, ha már egyszer el lett végezve a munka, többször ne kelljen ha lehet), aztán utána full AKARI tesztek. Jó lenne ha minden mostani funkció menne vele.
- A hozzászóláshoz be kell jelentkezni
AKARI-hoz infó:
http://sourceforge.jp/projects/tomoyo/lists/archive/users-en/2010-Octob…
"Target systems:
Linux distributions shipped with kernels being compiled with LSM (linux
security modules) framework support. That is, at least,
Red Hat Enterprise Linux (RHEL4(2.6.9)/RHEL5(2.6.18)/RHEL6(2.6.32))
Fedora (from Fedora Core 2(2.6.5) to Fedora 14(2.6.36))
Ubuntu (from Warty(2.6.8) to Maverick(2.6.35))
Debian (Sarge(2.6.8)/Etch(2.6.18)/Lenny(2.6.26)/Squeeze(2.6.32))
openSUSE (from 9.1(2.6.4) to 11.3(2.6.34))
should be supported. But please understand that AKARI cannot be used on some
of kernels listed above because of distributor specific kernel patches or
kernels being compiled without LSM framework support.
AKARI fails to register on some CPU architectures because it depends on
binary code scanning for finding functions/variables which are not exported
to LKM. Currently only x86_32 is known to work. I haven't tested (or cannot
test) other architectures (e.g. x86_64, IA64)."
http://comments.gmane.org/gmane.linux.tomoyo.user.english/250
If you want to use more functionality than TOMOYO 2.x but you don't want to
replace kernel package, you can try AKARI. AKARI can run on all 2.6 kernels
built with LSM support, although tested on only x86_32 and x86_64.
- A hozzászóláshoz be kell jelentkezni
néhány apróságot még ki szeretnék mielőbb javítani tomld-ben. pl.: a kivételeknél a shell-ek binárisainak útvonalt az /etc/shells -ből vegye (ugye ezekhez nem csinál fő domain-t, mert kizárhatjuk magunkat, illetve felesleges is ezekhez, mert úgyis lesz hozzájuk szabály másik domain aldomain-jeiben), plusz sshd csak akkor legyen kivétel, ha azon keresztül kapcsolódik, amikor a szabályt generálom tomld-vel stb.
redhat-et, centos-t, fedora-t és suse-t használók tudnának infót adni abban a kérdésben, hogy mindegyik fő disztrón szabvány az /etc/shells fájl? sok időt spórolnék vele.
- A hozzászóláshoz be kell jelentkezni