tomld vs Tomoyo 2.4

Elkezdtem írni a fejlesztőnek egy I'd like to express my frustration about.. kezdetű levelet, aztán úgy döntöttem hogy inkább leblogolom ide azt annyi.

Olyan szintű strukturális változásokat eszközöltek Tomoyo 2.4-ben 2.3 és előttiekhez képest, hogy valószínűleg dobom a projektet.

A profile.conf fájlt major verziónként változtatták, immáron harmadszor. Minek? Semmi új paramétert nem hozott be az mellett, hogy nagyon szar a felépítése. Így néz ki most (comment sorokat kihagyva): 


0-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
0-CONFIG={ mode=disabled grant_log=no reject_log=yes }
1-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
1-CONFIG={ mode=learning grant_log=no reject_log=yes }
2-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
2-CONFIG={ mode=permissive grant_log=no reject_log=yes }
3-PREFERENCE={ max_audit_log=1024 max_learning_entry=2048 }
3-CONFIG={ mode=enforcing grant_log=no reject_log=yes }

Ezen kívül az exception_policy.conf-nál minden domain_initialize sor után oda került a "from any". Minek? Miért túlbonyolítani az egyszerű kezdeti felépítést? Sem parsolni nem egyszerűbb, sem az olvashatóságot nem javítja.

A domain_policy.conf fájlban minden domainhez oda kell tenni a "use_group 0" sort. Minek ha alapból nem használjuk? De ennél is nagyobb probléma és baromság, hogy a meglévő tagokat (file_read, file_write, file_truncate stb.) teljesen átvariálták 2 oszlopba így: "file read", "file read/getattr" meg hasonlók. A nagyon egyszerű olvashatósága a kezdeti felépítésnek katasztrofális lett. Eredetileg úgy nézett ki, hogy pl.: "file_read fájlneve", ennyi. Most a 2 oszlop lehet 4 vagy 5 is. Nem is bírom most leírni megfelelően megfogalmazva az egészet.

Nem érdekelnek a kifogások, tartom amit többször leírtam itt: soha senki nem fogja használni azt a szoftvert, ami ennyire bonyolult. Kudarcnak ítélem meg, ha a szoftver könnyebb kezelhetőséget nem hoz a következő verzióban, csak a komplexitást növelik - pedig bonyolítani rohadt egyszerű. Adaptív automatikus megoldásokat kell csinálni egy rohadt nagy zöld "start" gombbal a 21. században - kompromisszumok nélkül. Ne én legyek a házért, hanem fordítva.

Sajnálom hogy pont ott voltam a küszöbön, hogy bekerüljön a progim a hivatalos repo-ba. Ez lett volna a pont az i betűn. Most kezdtem átdolgozni 2.4-es Tomoyo-hoz és kompatibilissé tenni. Felével megvoltam amikor eljutottam a domain_policy.conf-os állatsághoz. Egy kicsit hullámvasút volt, mert pár nappal ezelőttig a 2.3-asig kompatibilissel (0.76) úgy voltam, hogy szinte szarrá teszteltem (amennyire magam tudtam), és ha bekerül a repo-ba, mindenki egyszerűen tudja használni, meg utána fixálom szépen a kicsi a bug-okat, mindenféle nagyobb strukturális változások nélkül.

Áhh, dühös vagyok hogy ki kell dobnom ennyi melót, és nincs egyetlen alternatíva sem, ahol egy paranccsal megcsináltathatok magamnak MAC policy-t a rendszeremhez, és olyan egyszerű a felépítése mint az ezelőtti Tomoyo verzióknak.

( muczy v | 2011. 12. 18., v – 19:23 )

Ez bizony szomorú... Nem igazán értem miért kell nem major verzióváltásnál bármilyen hasonló változtatást (tehát nem hozzáadást) csinálni. Ilyen az amikor nincs egy erőskezű, összeszedett vezetés...

1 hivatalos fejlesztő van és egy hivatalos tesztelő AFAIK, de úgy látom csapong az alapdolgokkal kapcsolatban is. A 2.2 --> 2.3 váltásnál jött be pl. az umask dolog. Egy fájl létrehozásánál ez helyett: 

file_write /tmp/file.txt

..ez kell 2.3-tól: 

file_write /tmp/file.txt 0755

Ez is minek? Nem ezen fog állni vagy bukni a security. Úgy gondolom hogy egy bizonyos szint felett a lehetőségek növelésével (ami a komplexitást növeli) nem lesz egyértelműbb a használat.

Az a baj, hogy Tomoyo csak a feladat egyik felét adja. Biztosítja a user-nek, hogy összekaparhat magának kézzel 5000 szabályt a saját rendszeréhez, de senki nem garantálja, hogy a manuális turkálás során nem lesz tele hibával.

( johnny_b | 2011. 12. 18., v – 19:29 )

Tudom, utaljuk meg minden, de mit gondolsz a forkolasrol? Ha vannak konkret elkepzeleseid es erzel eleg magadban, akkor hajra!
(Ez egy batorito, "Fel a fejjel!" tipusu hozzaszolas.)
______________________________
Nä Ki'i No Ka 'oi Ma Ka Honua

( hrgy84 | 2011. 12. 19., h – 12:00 )

Kar, pedig filoztam, hogy az uj szerveren kiprobaljuk. De kezzel nem akarok szabalyokat gyanyolni, se idom nincs ra, se kedvem hozza.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( uid_2716 | 2011. 12. 20., k – 03:13 )

Huhh, ilyenen még mezei otthoni gyökérként is tombolni kezdek (általában nincs config file upgrade script), nemhogy függő projekt fejlesztőjeként... Részvétem. Esetleg annyit megkérdezhetnél tőlük, hogy erre miért volt szükség.

A szóközös opciókról egyébként az smb.conf jut eszembe. Annál nagyobb borzalmat nehéz elkövetni. Ugyanarra az opcióra több szinoníma ill. írásmód, egymást átfedő opciók stb...

Az a baj, hogy év eleje óta ez a harmadik .conf vájl verzió mindegyik fájlnál, és nem bízok a fejlesztőben hogy következő kiadásban nem gondolja meg magát gyökeresen az eddig kialakítottakkal kapcsolatban.

Bár olyan még eszembe jutott, hogy tomld-nek a konfig fájlt egy sed -r s/"^file *"/"allow_"/g parancs után dobom oda, utána meg visszaalakítom, de szerintem nem éri meg a fentebb írtam miatt.

Mindenképpen meg akartam kérdezni a fejlesztőt, hogy ezt miért? De lehet inkább tojok az egészre, és megvárom a következő Debian kiadást, hogy addigra mit kotornak össze. A Tomoyo-s levlistán egyébként tegnap bejelentette a fejlesztő, hogy Debian engedélyezte hivatalosan a kernelben AppArmor-t is, és hogy szállítani fogja a jövőben. Ugye Tomoyo-ban pont az tetszett, hogy szállította Debian és Ubuntu is, és most már a megjelent openSUSE 12.1 is. Más MAC meg nem volt eddig SELinux-ot kivéve Debian-ban hivatalosan.