log69 logo
blog
tomld
aaphoto
súgó
galéria
linkek
adomány
kapcsolat

lang
súgó

tomld:
Mi a célja?
Hogyan működik?
Mi van ha egy domain túl korán kerül kikényszerítő módba kapcsolásra?
Mennyire könnyű használni?
Mi szükséges hozzá?
Milyen jellemzőkkel bír?
Hogyan lehet beszerezni?
Mennyire általános megoldás ez?
Mennyire biztonságos?
Mennyi CPU és memória szükséges neki?
Nem jobb kézzel létrehozni Tomoyo szabályokat?
Használhatók előzetesen készített Tomoyo szabályok tomld-hez?
Milyen beállítások vannak /etc/tomld/tomld.conf fájlban?
Miért vannak kivételként megjelölve a shell binárisok?
Ki szponzorálja ezt a projektet?
Egyéb megjegyzések
Hibajegyzék


Mi a célja?

A projekt Tomoyo biztonsági eszköz használatának megkönnyítésére született. Elsődleges cél egy biztonságosabb szoftver környezet létrehozása teljes automatizációval felhasználói beavatkozás szükségessége nélkül.


Hogyan működik?

Tomld létrehoz domain-eket szabályokkal olyan alkalmazásokhoz, amelyek hálózaton figyelnek, vagy amelyeket a felhasználó kért. Úgy növeli a biztonságot, hogy bezár minden programot egy domain-be a szabályrendszer kikényszerítésével.

Tomld nyomon követi minden domain létrehozási idejét, utolsó változás idejét és a cpu használatát. A domain komplexitása kikalkulálásra kerül és minél komplexebb, annál több időt kap tanuló módban. Mikor a cpu használat elér egy határt a komplexitást is figyelembe véve, akkor a domain-t átkapcsolom kikényszerítő módba. Miután kikényszerítő módban van, a tanulási fázisnak vége.

Van egy abszolút határa is a tanuló időnek, ez jelenleg 2 hét.


Mi van ha egy domain túl korán kerül kikényszerítő módba kapcsolásra?

Ha egy domain kikényszerítő módban van, akkor már nem férhet hozzá több dologhoz mint amely a szabályaiban meg van határozva.

Ha a domain-nek több idő kellene, mert valami még kimaradt (ez akkor fordulhat elő például, ha egy funkcionalitást nem használtak a tanuló idő alatt), akkor még van lehetősége a felhasználónak átmeneti tanuló időt kérni 'tomld --learn' parancs futtatásával. Ez jelzi a futó tomld szolgáltatásnak, hogy kapcsoljon vissza a következő ciklusnál minden olyan és csak olyan domain-t tanuló módba, amelyekhez hozzáférés megtagadás került naplózásra most. Ez az átmeneti tanuló idő maximum 1 órán át tart, vagy amíg a domain megint kikényszerítő módba kapcsolódik, vagy amíg tomld kilép.


Mennyire könnyű használni?

Mindösszesen egy .deb csomag telepítése az egész. Egyetlen újraindítás kellhet még Tomoyo aktiválásához ha még nem aktív, és ennyi. Tomld szolgáltatásként fog futni és elvégzi a többit innétől.

Nincs szükség a parancssor használatára desktopon sem. A csomag feltesz két ikont. Az egyik az információs szolgáltatás elindításához, a másik pedig átmeneti tanuló mód kéréséhez ha bármilyen probléma merülne fel.


Mi szükséges hozzá?

Tomld kizárólag Linux-hoz készült megoldás, ezért egy Tomoyo-val fordított Linux kernelre van szükség (v2.6.30 - 3.0.x), a Tomoyo eszközöknek is telepítve kell lenniük (v2.2 - 2.3.x) és a rendszert "security=tomoyo" kernel paraméterrel kell indítani.

Debian vagy Ubuntu rendszeren, tomoyo-tools csomagot telepítsük.

A tomld Debian csomag két másik csomagtól is függ: libnotify-bin és su-to-root a jobb asztalba épüléshez, de ezek nem szükségesek.


Milyen jellemzőkkel bír?

- 1 klikkes megoldás, nincs szükség a parnacssorra

- az aktuális szabályok analizálása külső extra információ adatbázisban való tárolása vagy egyéb más mód nélkül

- teljes automatizációval rendelkezik, melyben eldönti mely fájlok kerülnek kicsillagozásra és mely domain-ek lesznek kikényszerítő módba kapcsolva és mikor

- chroot-ból indított folyamatok felismerése és ezek szabályainak a chroot könyvtárhoz viszonyított kezelése

- emlékezik a domain létrehozási idejére, utolsó változás idejére és a használt cpu mennyiségre még újraindítás után is

- elmenti a szabályokat újraindításkor vagy az alkalmazás bezárásakor

- mentést készít bizonyos műveletek végzésekor

- segít kikerülni a túl sok szabály által okozott szolgáltatás megtagadást úgy, hogy ha túl sokáig tart egytlen futási ciklus, akkor figyelmeztető üzenetet nyomtat a megoldással együtt (--info kapcsoló áttekintést ad a legtöbb bejegyzéssel rendelkező könyvtárakról, és ezek közül némelyik betehető a [recursive] tag alá a konfig fájlban)

- visszaállítás funkció az adatok utolsó mentésből való visszaállítására

- biztonságot szem előtt tartva nem figyel hálózati socket-en és nem fogad külső bemenetet

- tiszta C kód extra függőségek nélkül Tomoyo-n kívül

- kis memóra felhasználású egy mai modern asztali vagy szerver gépen

- spórol merevlemez hozzáférést amikor csak lehetséges

- energia takarékos módba kapcsol miután minden domain kikényszerítő módban van úgy, hogy tízszer többet alszik minden ciklusban


Hogyan lehet beszerezni?

Ha magadnak akarod fordítani, akkor töltsd le a csomagolt fájlt és tömörítsd ki. Ha a fordításhoz szükséges megfelelő eszközök már a gépen vannak, akkor 'make install' parancsot futtatva létrehozza a futtatható állományt és telepíti a rendszerbe. tomoyo-tools-nak telepítve kell lennie tomld működéséhez.

Ha csomagot szeretnél használni, akkor Debian csomagok (32 és 64 bit) elérhetőek tomld.tgz fájlban a dist_debian könyvtáron belül. Ezek Debian-hoz (6.x és felfelé) és Ubuntu (10.10 és felfelé) rendszerekhez vannak.

A telepítéshez futtatsd ezt a parancsot a megfelelő .deb fájllal: sudo dpkg -i tomld*.deb; sudo apt-get -f install

OpenSUSE engedélyezni fogja a Tomoyo támogatást gyárilag a kernelben a 12.1-es rendszertől kezdve, ezért tervezem .rpm csomagok létrehozását is.


Mennyire általános megoldás ez?

Nincsenek belekódolva semmilyen más szoftver beállításai vagy könyvtár nevei, hogy a lehető legáltalánosabb megoldás lehessen. Működnie kell bármely Linux alapú rendszeren.

Meg kell húzni a vonalat a biztonság és használhatóság között, tomld megfelelő biztonságot nyújt a használhatóság feláldozása nélkül.


Mennyire biztonságos?

A tomld szolgáltatás nem hív meg semmilyen külső alkalmazást futás közben (--mail és --notify opciók nélkül), kivéve egyszer a tomoyo-loadpolicy binárist első alkalommal, hogy jogot szerezzen a későbbi Tomoyo domain-ek módosításához.

Nem figyel hálózati socket-en és nem lehet vele kommunikálni egyet kivéve, ez az átmeneti tanuló mód kérése a /var/run/tomld/tomld.learn fájlon keresztül 'tomld --learn' parancs futtatásával (a domain-ek nem férhetnek hozzá tomld munka könyvtáraihoz).


Mennyi CPU és memória szükséges neki?

Átlagban 1-3% CPU-t használ tomld futás közben. Egy régebbi gépnek (3-4 éves vagy régebbi) több időre lehet szüksége a futáshoz. A maximális virtuális memória valahol 6 és 60 MB között van, míg a rezidens memória pedig 1 és 20 MB között.

Tomld több CPU-t igényel szabályok generálásakor.


Nem jobb kézzel létrehozni Tomoyo szabályokat?

Nem, legalábbis gyakorlati szempontból; amikor megpróbálunk domain-eket és szabályokat létrehozni manuálisan, akkor ki kell találni, hogy mely alkalmazásokat akarjuk bezárni és azokhoz mely folyamatok tartoznak. Mélyen ismernünk kell a rendszert ehhez. El kell tudnunk dönteni, hogy mely fájlokat írhatják és melyeket csak olvashatják, mikor van vége a domain tanuló módjának és mely domain-eket kell visszakapcsolni kikényszerítő módból probléma esetén. Frissíteni is kell a szabályokat időröl időre, mert egy rendszer frissítéssel változhatnak komponens verziók, új szoftverek is települhetnek, vagy egyszerűen bármely része változhat a rendszernek a mindennapos használat alatt.

Ami szintén megnehezíti a Mandatory Access Control (MAC) használatát, hogy még hasonlónak tűnő rendszereknek is különböző MAC szabályok szükségesek. Különbözhet abban, hogy milyen szoftverek vannak telepítve és milyen módon, melyek és hol vannak a könyvtárak és fájlok. Ezért nem kivitelezhető a szabályok másolása rendszerek között.

Habár lehetnek esetek, mikor direkt kézzel szerkesztett Tomoyo szabályok szükségesek, és ezek némely esetben jobbak és biztonságosabbak lehetnek, ez nem az átlag felhasználónak való. Mindez több ezer szabálynál már nem tűnik kivitelezhetőnek. Idő igényes és nehezen megvalósítható.


Használhatók előzetesen manuálisan készített Tomoyo szabályok tomld-hez?

Nem. Tomld saját módján és logikája alapján hoz létre szabályokat. Inkompatibilitás lehet a kézzel létrehozottak között. Nem ajánlott.

Amikor futtatjuk tomld-t, akkor üres szabályokat hoz létre és elmenti az előzőket, ha azok eredetileg nem tomld által készített szabályok voltak.


Milyen beállítások vannak /etc/tomld/tomld.conf fájlban?

Minden tagnak alatta találhatóak az értékei, soronként egy. Szóközök és üres soros nem számítanak. A '#' karakterrel kezdődő sorok megjegyzésnek számítanak és figyelmen kívül lesznek hagyva. Az elérési utak tartalmazhatnak wildcard-okat. '\*' egy wildcard és '\{\*\}' egy rekurzív wildcard amely bármely számú és nevű alkönyvtárat jelent itt. Rekurzív wildcard-ot csak egyszer használhatunk elérési utanként, és csak a végén.

[mail] Tomld e-mailt fog küldeni az alább megadott személyeknek az összes aktuális hozzáférés megtagadásról. Ha nincs beállítva, akkor a /var/log/tomld.log fájl használható a napló fájlok megtekintéséhez.

[notify] Tomd futtatni fogja az alábbi parancsot hozzátoldva az üzenetét mikor fontosabb esemény történik.

[exception] A megadott könyvtárakban lévő fájlok nem kerülnek kicsillagozásra automatikusan. Ha a fájl egy váletlen fájl, akkor csak a véletlen rész kerül kicsillagozásra. Az ötlet eredetileg az, hogy nem engedek olvasni minden fájlt ezekben a könyvtárakban, úgymint .gnupg könyvtár a home könyvtárban, vagy /etc/passwd /etc-n belül.

[wildcard] Ezekben a könyvtárakban lévő fájlok mindig kicsillagozásra kerülnek, függetlenül attól, hogy a szabály írásra van vagy csak olvasásra (tomld alap ötlete az, hogy minden fájlt kicsillagozok az írásra való szabályokban, mint létrehozás, átnevezés, törlés stb., és a többi helyen érintetlenül hagyom). Ez hasznos nem annyira fontos könyvtárakon belül, mellyel az esély megnő a végleges szabályokhoz és a tanuló idő befejezéséhez.

[replace] Az elérési utak a domain szabályaiban le lesznek cserélve ezekre a könyvtárakra, ha az itteniek "általánosabbnak" tűnnek a több kicsillagozott résszel bennük. Az eredeti ötlet az, hogy meglegyen a lehetőség a kézzel kicsillagozására, ha tomld nem tudja ezt megoldani automatikusan. Néha könyvtár nevekben is van véletlennek tűnő rész. Habár ez nem gyakori, mégis nehéz egy általános megoldást adni rá. Egy ilyen példa a 3-as verziójú GDM könyvtár szerkezete amely így néz ki: /var/run/gdm/auth-for-X5gGF53/, ahol "X5gGF53" a véletlen szerűen generált rész, amely mindig újra generálódik újraindítás után. Ha ezt nem csillagozzuk ki, akkor a szabályok soha nem véglegesítődnének.

[recursive] Mindig minden kicsillagozásra kerül rekurzívan ezen könyvtárakon belül. Lehet értelme betenni ide egy olyan könyvtár nevet, amihez tomld nem tudott általános szabályt adni és állandóan új szabályt generál hozzá (pl. új véletlen nevű könyvtárak). Szintén be lehet tenni ide pl. '/home/user/.mozilla' könyvtárat vagy samba megosztásokat. Fontos, hogy ezt az opciót körültekintéssel használjuk, mert a túl sok rekurzív helyettesítés Tomoyo hasznosságát csökkenti.

[nocrypt] Kikapcsolja a csatlakoztatott titkosított fájlrendszerek automatikus keresését.

[nodomain] Az ez alatti összes bejegyzés extra futtatható állományként lesz kezelve, amelyekhez _nem kell_ domain-t kell létrehozni.

[extra] Az ez alatti összes bejegyzés extra futtatható állományként lesz kezelve, amelyekhez domain-t kell létrehozni.


Miért vannak kivételként megjelölve a shell binárisok?

A kivétel azt jelenti, hogy tomld nem hoz létre fő domain-t az adott binárishoz vagy folyamathoz. De ettől még az lehet másik aldomain vagy fő domain aldomain-je.

Tegyük fel, hogy a felhasználó bezárja a bash binárist egy domain-be. Ha tomld létrehoz neki egy initialize_domain tagot az exception policy-ben Tomoyo-n belül, akkor minden bash folyamat ebbe a domain-be kerülne átvezetésre és az itteni szabályok vonatkoznak rájuk. Mivel egy shell-nek mindent meg kell engedni, ezért egy általános szabályt nem lehet csinálni hozzá.

De ez nem is szükséges, mert minden shell-t használó domain létrehozza a saját aldomain-jét, és az itt létrejött szabályok fognak vonatkozni azokra a shell-ekre, amelyek kizárólag ezekből a domain-ekből kerülnek meghívásra.

sshd és screen is alapértelmezett kivételek. A lehetőségek még változhatnak itt, további tesztek szükségesek annak eldöntésére, hogy mi a legjobb általános szabály vagy milyen opciókat engedjek meg a felhasználónak.


Ki szponzorálja ezt a projektet?

Senki. Én járulok hozzá a saját időmből díjmentesen.


Egyéb megjegyzések

- tomld feltételezi, hogy egy teljesen megbízható környezetben kerül futtatásra

- az alkalmazásokat maximális lehetséges módon kell használni a tanuló fázis alatt, hogy minden viselkedésre legyen egy szabály

- --clear vagy --reset kapcsolónál a konfigurációs fájlok elmentésre kerülnek és az előző napló fájlok figyelmen kívül leszenk hagyva, ez megfelel egy új, alapértelmezett beállításnak

- tomld fájlok:
/var/local/tomld/tomld.logmark (ez egy olyan azonosítót tartalmaz, amely a már olvasott napló fájlok végét jelzi)
/var/local/tomld/tomld.logmark.learn (ez ugyanaz, csak átmeneti tanuló módhoz használva)
/var/run/tomld/tomld.pid (pid fájl a program egyidőben való több példányú futtatásának kikerüléséhez)
/var/run/tomld/tomld.learn (fájl az átmeneti tanuló mód jelzéséhez a futó szolgáltatásnak)
/var/run/tomld/tomld.learn.list (minta list az átmeneti tanuló módhoz olyan domain-ekhez, amelyek illeszkednek ezekre a mintákra)
/var/run/tomld/tomld.message (fájl a legfrisebb fontos üzenetekkel az információs szolgáltatáshoz)
/var/run/tomld/tomld.message.lock (lock fájl az előzőhöz)
/etc/tomld/tomld.conf (beállítások)

- ha egy szoftver vagy a beállításai változnak egy új verzióval, akkor a szabályok könnyen újragenerálhatók

- a futó folyamatokat újra kell indítani, ha új domain kerül beállításra nekik

- auto igen (yes) opció mindig ki van kapcsolva manuális módban hozzáférés megtagadás feldolgozásánál

- ha valaki nem akarja állandóan futtatni tomld-t, akkor egyszerűen leállítható és eltávolítható a szolgáltatások közül miután minden domain tanuló módja véget ért és szükség esetén újra futtatható

- a folyamat ábra megtalálható a forrás kód elején

- tesztelve több mint 6000 inaktív domain-el, több mint 60 aktív domain-el és több mint 3000 szabállyal a kernel memóriában, még mindig elfogadható sebességet adott


Hibajegyzék

- nincs tudomásom hibáról jelenleg



aaphoto:
Hogyan működik?
Telepítés forráskódból
Egyes képeken miért kisebb a javítás mértéke, míg másokon erősebb?
Miért keletkezik mégis néhány esetben rosszabb eredmény?
Miért nincs a programnak olyan egyéb kapcsolója, amellyel befolyásolható a korrekciós folyamat?
Egyéb megjegyzések


Hogyan működik?

Ez a szoftver egy parancssori alkalmazás, terminálból vagy parancssori ablakból futtatható. Bemenetként paramétereket és fájl neveket fogad. Például:

aaphoto image.jpg

Ez létrehoz egy "image_new.jpg" nevű fájlt, ami a színkorrigált kép lesz.


Telepítés forráskódból

A legfrisseb verziót Debian rendszeren:

su -c "apt-get install build-essential libjpeg-dev libjasper-dev libz-dev libpng-dev"

wget http://log69.com/downloads/aaphoto_sources.tar.gz

tar xf aaphoto_sources.tar.gz

cd aaphoto-*

./configure && make && su -c "make install"


Egyes képeken miért kisebb a javítás mértéke, míg másokon erősebb?

Mivel különböző képek különböző mértékű korrigálásra szorulnak, ezért a program változó módon korrigálja a képeket.

Ha egy képnek jó a kontraszt beállítása, akkor az nem kerül állításra, ezért a végeredményen kisebb változást veszünk észre.


Miért keletkezik mégis néhány esetben rosszabb eredmény?

A program analizálást végez és újrakalkulálja a kép színeit. Egy automatizált algoritmusnak a feladat szempontjából döntéseket kell hoznia. Viszont automatizációval nehéz minden bemenetre jó döntést hozni.

Ezért olyan megoldásra törekedek, amelynél inkább kevesebb döntést hozzon a program -ezzel kevésbé drasztikus állítás fogja jellemezni a keletkező képet- de viszont kevesebb is lesz a rossz kimenetek száma.

Az elsődleges szempont, hogy ha nem tud javítani a képen, azért rontani lehetőleg ne rontson.


Miért nincs a programnak olyan egyéb kapcsolója, amellyel befolyásolható a korrekciós folyamat?

A program kizárólagos célja a felhasználó megkímélése a paraméterezéstől és bemeneti értékek megadásától.

A program éppen annak a megoldására született, hogy egyszerűen lehessen korrigálni valamennyi fotó képet. A jövőben is ez irányába fog folyni a fejlesztés.


Egyéb megjegyzések

- Ha a kép belebélyegzett dátumot vagy egyéb keretet tartalmaz, az befolyásolja a kép egészének színeloszlását nem természetes módon és ez kihat a végeredményre

- Bemeneti képek 24 bites színes RGB vagy 8 bites Gray képek lehetnek, más színmódot tartalmazó képek nem kerülnek feldolgozásra

- Sok fájl helyett inkább mappára indítsuk rá a konverziót

- A --test kapcsoló töb hisztogrammot rajzol a végeredmény képébe, amelyek az analizálás előtti és utáni állapotot mutatják
1. hisztogram: eredeti állapot
(fehér vonal mutatja meg a barna háttérrel, hogy meddig vágjuk le a kontraszthoz)
2. hisztogram: kontraszt állítás után
(fehér vonal mutatja meg a barna háttérrel, hogy hova kell húzni a gammát)
3. hisztogram: színtelítettség állítás előtt
(fehér vonal mutatja meg a barna háttérrel, hogy mennyi színtelítettség állítás lesz, vagy mennyit veszünk vissza)
4. hisztogram: a végeredmény állapota
5. színérték körrel: két egyenes mutatja a kontraszthoz megállapított fehér és fekete pont színének írányát és mértékét