Az AppArmor biztonsági céljai

Titkosítás, biztonság, privát szféra

Crispin Cowan egy, az LKML-re küldött dokumentumban foglalta össze az AppArmor névre hallgató biztonsági mechanizmus céljait. A dokumentum nem arról szól, hogy hogyan működik az AppArmor és nem is arról, hogy miért kellene az AppArmor-t más, hasonló céllal készült megoldás helyett használni.

Az AppArmor célja, hogy megvédje a rendszert azoktól a támadásoktól, amelyek a rendszeren található alkalmazások hibáit akarják kihasználni. Az ilyen támadásokból adódó fenyegetés abban rejlik, hogy a támadó rossz esetben rá tudja venni az alkalmazást olyan viselkedésre, ami tőle váratlan és nemkívánatos. Az AppArmor úgy próbálja lekezeli ezt a problémát, hogy lekorlátozza az alkalmazások erőforrásokhoz való hozzáférhetőségét és kizárólag csak azokhoz az erőforrásokhoz engedi hozzáférni őket, amelyek feltétlenül szükségesek a megfelelő futásukhoz. Tulajdonképpen a "lehető legkisebb privilégiumszintű végrehajtásra" szorítja az alkalmazást.

Az alkalmazások számos erőforráshoz - file-okhoz, processzek közti kommunikációhoz (IPC), hálózatkezeléshez, más alkalmazások futtatásához, stb. - férhetnek hozzá. A "lehető legkisebb privilégiumszintű végrehajtás" célja, hogy korlátozza a rosszindulatú támadó (vagy kód) által okozható kárt azzal, hogy megakadályozza az alkalmazás összes olyan erőforráshoz való hozzáférhetőségét, amely nem szükséges az eredetileg tervezett működéséhez.

Az AppArmor megközelítésben egy "alkalmazás" egy vagy több olyan egymással kapcsolatban álló processzt jelent, amely azonos feladatot lát el. Ilyen például az Apache processzek csoportja, amely webkiszolgálási feladatot teljesít. Az AppArmor *csak* azokat a processzeket korlátozza, amelyekre az AppArmor policy rendelkezik, egyéb más processzek bármit megtehetnek, amire a DAC (Discretionary Access Control - önkényes hozzáférés-védelem) lehetőséget biztosít. Az AppArmor nem ad olyan alapértelmezett policy-t, amely minden processzre vonatkozik. Ha teljes egészében meg akarunk védeni egy hostot, akkor aprólékosan le kell korlátoznunk minden olyan processzt, amely potenciális támadásnak van kitéve.

Az AppArmor leírása itt folytatódik.

( x-daemon | 2007. 11. 09., p – 22:02 )

azt hogy egy alkalmazasnak pontosan milyen eroforrasokra van szuksege a tervezoi tudjak megmondani. nekik kell az alkalmazas melle csomagolni az alkalmazashoz tartozo policyt.
az apparmornak pedig bekapcsolt allapotban nem szabad olyan alkalmazas futasat engedelyezni amihez nincs policy.
ugye nem nekem kell processzenkent hegesztenem hogy vajon milyen eroforras kellhet neki...? :)

nyilt forras nem garancia. kovetkezo mondatodat nem hallottam :) akar szandekos akar veletlen egy programnal a kar okozasa, az eroforras korlatozasa reven az okozott kar is korlatozva van. a tervezoje tudja azt hogy milyen eroforrasok kellenenek a megfelelo mukodesehez, a tobbi eroforrashoz meg semmilyen korulmenyek kozott ne jusson hozza. szerintem.

mivel mar a hw architektura sem biztonsagi szempontok alapjan lett megtervezve, nincs olyan program amiben megbiznek. az hogy hasznalom az azert van mert vallalom a kockazatot :) de megbizni nem bizom meg benne. en az ilyen megoldasokra mint "remelhetoleg kockazat csokkento" megoldasokra tekintek nem mint "kockazat nullara redukalo" ultimate megoldasokra.

> a tervezoje tudja azt hogy milyen eroforrasok kellenenek a
> megfelelo mukodesehez, a tobbi eroforrashoz meg semmilyen
> korulmenyek kozott ne jusson hozza. szerintem.

szerintem meg csak nem gondoltad at a fentit ;). ime egy program, amit en terveztem, de gozom sincs rola, hogy milyen eroforrasigenye van/lesz, igy azt sem tudom, megmondani, hogy mihez nem ferhet hozza 'semmilyen korulmenyek kozott': 

#include <unistd.h>
int main(int argc, char *argv[]) {return argc ? unlink(argv[1]) : 0;}

azt ugye nem mondod komolyan hogy olyan programot tervezel amirol nem tudod hogy milyen eroforrasokhoz ferhet hozza? :) nem azert nincs gozod rola, mert nem definialtuk az eroforrasokat? :) ha egy keretrendszerben egyertelmuen definialva vannak az eroforrasok, akkor meg tudod mondani hogy a programod melyiket fogja hasznalni leven a program azon reszei amik nem a belso mukodese azok eroforrasokhoz valo fordulasok. a te peldadban ha definialjuk az unlink es mkdir eroforrasokat akkor meg tudod mondani hogy az unlink eroforrashoz kell hogy joga legyen az mkdirhez pedig nem. en a sajat helyemben egy olyan operencias rendszert mint keretrendszert tudnek elkepzelni, amiben minden olyan funkciot ami hatassal lehet egy masik benne futo alkalmazasra vagy magara az operencias rendszerre eroforraskent definialnam es a benne futo alkalmazas inditasa elott az alkalmazas futasahoz szukseges eroforrasoknak egyertelmuen definialva kellene lenniuk. nem allitottam azt hogy letezik ilyen operencias rendszer de ha magamat kerdezem az apparmornak azt a celjat hogy egy alkalmazasnak az eroforrasokkal valo varatlan es nemkivanatos mukodeset kikuszoboljuk egy jo modszer lenne.

> azt ugye nem mondod komolyan hogy olyan programot tervezel amirol
> nem tudod hogy milyen eroforrasokhoz ferhet hozza? :)

nem ertem a smiley-t. teljesen komolyan gondoltam, amit irtam. sot elarulom, hogy a legtobb (kvazi minden nem trivialis) program olyan, hogy elore nem lehet megmondani az eroforrasigenyet (pongyolan fogalmazva, hogy 'mit fog csinalni', pl. minden interpreter ilyen (ill. ugy altalaban minden univerzalis turing gep)). megpedig azert, mert nem a programon mulik, hanem a hasznalojan (vagyis: az inputon).

de ha te maskepp gondolod, akkor hajra, definiald az altalam megadott (rem egyszeru) peldaprogram eroforrasigenyet. vagyis latom, hogy megprobaltad, nezzuk akkor, hogy hol rontottad el:

> te peldadban ha definialjuk az unlink es mkdir eroforrasokat akkor
> meg tudod mondani hogy az unlink eroforrashoz kell hogy joga legyen
> az mkdirhez pedig nem.

ez szep es jo, de nem elegseges. a programnak ui. nem csak ennyire van szuksege a helyes mukodeshez. tegyuk fel, hogy en, mint felhasznalo, azt akarom, hogy a programom hozzaferjen a /home/paxteam/titok file-hoz, de ne ferjen hozza az /etc/shadow-hoz. nem latom, hogyan jon ez az igeny ki a te allitasodbol (vagyis: sehogy). aztan a csavar: tegyuk fel, hogy pont forditva akarom a viselkedeset meghatarozni. ugye azt nem akarod allitani, hogy kepes vagy egyszerre valamit meg annak az ellenkezojet is kiolvasni a programkodbol? ;-)

na mire akartam mindezzel ramutatni: a gyakorlatban hasznos programok (meg az en 2 sorosome is) viselkedese mindig az inputon mulik, elore nem lehet megmondani pontosan. az apparmor meg mas MAC rendszerek celja nem is ez, hanem az felhasznaloi igenyek leirasa. ez azt is jelenti, hogy ugyanannak (!) a programnak kulonbozo dolgokat engedhet meg egy masik felhasznalo mint te vagy en. vagyis a programbol nem lehet kiolvasni a szukseges teljes policy-t.

kevered a dolgokat. eroforraskent definialtal objektumot. na de nezzuk sorjaban.

"a legtobb (kvazi minden nem trivialis) program olyan, hogy elore nem lehet megmondani az eroforrasigenyet (pongyolan fogalmazva, hogy 'mit fog csinalni'"

dehogynem tudom megmondani hogy mit csinalhat. a programod torolhet. az unlink() eroforrast fogja hasznalni. mas eroforras hasznalata nem engedelyezett.

"minden interpreter ilyen"

mivel az interpreternek engedelyezni kell az osszes eroforras hasznalatat amit az interpretalt nyelv interpretalasa soran hasznalnia kell - pl ha az interpretalt nyelvben is szerepel az unlink() akkor az interpreternek engedelyezni kell a rendszer unlink() eroforrasat - , ezert az interpretalt nyelvben megirt programnak is le kell korlatozni az eroforrasait az interpretalt program altal hasznalt eroforrasokra, neki is kell egy policy file. pl az interpreternek az unlink() es mkdir() eroforrasokhoz van joga, de az interpretalt torloprogramnak csak az unlink()-hez:

/etc/policy/bin/interpreter:
unlink()
mkdir()
EOF

/etc/policy/bin/torloprogram:
unlink()
EOF

/bin/torloprogram:
#!/bin/interpreter
unlink()
EOF

( egy program policyja az /etc/policy konyvtar alatt talalhato a program eleresi utvonalanak megfeleloen ugyanabban a konyvtarban. ez a szabalyrendszer csak pelda )

„nem a programon mulik, hanem a hasznalojan (vagyis: az inputon).”

az inputon nem mulik hogy mit csinalhat. torolhet. az inputon az mulik hogy mit akar torolni.

„ez szep es jo, de nem elegseges. a programnak ui. nem csak ennyire van szuksege a helyes mukodeshez”

a rendszer mukodesenek szempontjabol nem elegseges - szerintem így erted - , de a program mukodesenek szempontjabol igen.

„tegyuk fel, hogy en, mint felhasznalo, azt akarom, hogy a programom hozzaferjen a /home/paxteam/titok file-hoz, de ne ferjen hozza az /etc/shadow-hoz”

visszautalnek az elejehez. eroforraskent definialtal objektumokat. a rendszerben levo fileket azert sem definialnam eroforraskent, mert nem a program fogja eldonteni, nem az o joga eldonteni hogy letorolheti-e vagy sem az adott filet hanem a rendszer. en inkabb objektumnak definialnam a fileket.

„nem latom, hogyan jon ez az igeny ki a te allitasodbol (vagyis: sehogy).”

az agymenesemben csak a program altal hasznalt eroforrasok meghatarozasanak szuksegessegerol volt szo a rendszer teljes mukodeserol nem.

„aztan a csavar: tegyuk fel, hogy pont forditva akarom a viselkedeset meghatarozni.”

viselkedese 1 van. a torles.

”ugye azt nem akarod allitani, hogy kepes vagy egyszerre valamit meg annak az ellenkezojet is kiolvasni a programkodbol? ;-)”

gondolom nem ertetted amit irtam azert gondolod azt hogy olyat is kepes vagyok allitani aminek nincs ertelme :)
de a lenyeg, amit hianyolsz: azt hogy melyik objektumot tudja letorolni a program es melyiket nem, annak az eldontese nem a program feladata nem az o joga. azt hogy a program letorolheti-e az adott objektumot vagy sem azt a rendszer fogja meghatarozni a program es az objektum attributumai alapjan.

„na mire akartam mindezzel ramutatni: a gyakorlatban hasznos programok (meg az en 2 sorosome is) viselkedese mindig az inputon mulik, elore nem lehet megmondani pontosan.”

ha viselkedes alatt a vegeredmenyt erted vagyis hogy a fájl le lett-e torolve vagy sem, akkor a valasz igen. az inputon mulik. de nem az input miatt mert az egy szoveg, hanem annak az objektumnak az attributumai miatt amit meghataroz.

„az apparmor meg mas MAC rendszerek celja nem is ez, hanem az felhasznaloi igenyek leirasa”

ezt nem ertem.

„ez azt is jelenti, hogy ugyanannak (!) a programnak kulonbozo dolgokat engedhet meg egy masik felhasznalo mint te vagy en. vagyis a programbol nem lehet kiolvasni a szukseges teljes policy-t.”

a programbol ki lehet olvasni hogy mire terveztek, mik azok az eroforrasok amikhez hozza kell ferjen. az osszes tobbihez nem kell hozzaferjen. ezt persze tovabb lehet szukiteni, pl. legyenek felhasznalohoz rendelt eroforrasok is, ebben az esetben a program altal hasznalhato- es a felhasznalo altal hasznalhato eroforrasok konjukcioja adja meg azokat az eroforrasokat amelyeket az adott felhasznalo az adott programmal elerhet.

ha valamit meg nem tudtam erthetoen kifejezni szolj!

A file is "erőforrás":

Thus the AppArmor security goal should be considered piecewise from the
point of view of a single confined process: that process should only be
able to access the resources specified in its profile:

* can only access files that are reachable in its name space by path
names matching its profile, and only with the permitted modes:
read, append, write, memory map, execute, and link

a file objektum :)
az eroforrasok: "read, append, write, memory map, execute, and link" - amiket korlatozni lehet
az attributumok: "that are reachable in its name space by path names matching its profile" - amik alapjan eldol hogy van-e lehetosege, joga megtenni a fenti muveleteket
en errol az operencias rendszerrol beszelek, http://hup.hu/node/46817#comment-454931 az apparmor mukodeset nem ismerem :)
azert is irtam fentebb hogy a file nem eroforras, mert tobbek kozott ebben az esetben masik programot kellene irni a "/home/paxteam/titok" letorlesere mint a "/etc/shadow" letorlesere aminek nem sok ertelmet latom :)

Jam, az eredeti cikkben ez van:

"Applications have access to a number of resources including files,
interprocess communication, networking,"

"Az alkalmazásoknak hozzáférésük van számos erőforráshoz beleértve a file-okat, processzek közti kommunikációt, hálózatkezelést,"

A "resources" szóra jobbat nem tudok, mint "erőforrások". Fixme.

Az viszont biztos, hogy az AppArmor profile-okban konkrét file-okra (is) rendelkezhetünk. Pl. 

root@alderaan:/etc/apparmor# cat /etc/apparmor.d/abstractions/cups-client 
# vim:syntax=apparmor
# CUPS client access

  # discoverable system configuration for non-local cupsd
  /etc/cups/client.conf   r,
  # client should be able to talk the local cupsd
  /var/run/cups/cups.sock w,

--
trey @ gépház

> kevered a dolgokat. eroforraskent definialtal objektumot. na de
> nezzuk sorjaban.

keverni akkor tudnam oket, ha ismernem a *te* definicioidat rajuk. hajra, ne tartsd vissza ;-). addig is:

a legelso hosszaszolasod elso ket mondatabol az kovetkezik, hogy mivel (szerinted) a program iroja ismeri a programja altal igenyelt 'eroforrasokat', ezert neki kene szallitania a policy-t. a kesobbi (kulonosen az utolso) hosszaszolasod alapjan ugy tunik, hogy te nem tudod, mi az a policy, mi celt szolgal, es ezert kotod az ebet a karohoz. akkor megegyszer: egy MAC policy *NEM* a programok viselkedeset irja le (errol mindjart irok alabb), hanem a 'felhasznalo' biztonsagi igenyet fejezi ki. annyira igy van ez, hogy egy valos eletbeli policy siman megtilthat olyan dolgokat, amire a programnak szuksege van (aztan attol vagy tovabbra is hasznos marad vagy nem).

amiert te valoszinuleg felreertetted a policy szerepet az az, hogy amikor megnezel egyet, akkor azt latod, hogy tele van ilyesmikkel: 

/lib/ld-*.so                   mrix,
/lib64/ld-*.so                 mrix,
/lib/ld64-*.so                 mrix,
/lib64/ld64-*.so               mrix,
...stb

ebbol azt a kovetkeztetest vontad le, hogy akkor lam, a policy azt irja le, hogy mire van szuksege az adott programnak. ez a tevedes! a policy itt is azt irja le, hogy az adott 'felhasznalo' mit fogad el biztonsagi kockazatkent (a biztonsagtechnikaban minden a kockazatkezelesrol szol). pl. a fenti sorok azt fejezik ki, hogy a 'felhasznalo' elfogadja azt a kockazatot, amit a dinamikus linker kodjanak futtatasa jelent. se tobbet, se kevesebbet nem jelent. az egy teljesen mellekes korulmeny, hogy egy dinamikusan linkelt program el se indulna ezen szabalyok nelkul, attol meg a 'felhasznalo' (igazabol 'policy iro', a ketto nem feltetlenul azonos szemely vagy program) szandeka nem az volt, hogy kitalalja, hogy a program futasahoz mire van szukseg, hanem az, hogy miutan ezt kitalalta, tudatos dontest hozzon arrol, hogy mi jelent elfogadhato kockazatot, es mi nem. mivel szemmel lathatolag ugy dontott, hogy a dinamikusan linkelt programok elinditasa elfogadhato kozkazat, ezert megirta a fenti szabalyokat.

az unlink-es peldamra visszaterve: az edeskeves, hogy te engedelyezed az unlink 'eroforras' hasznalatat a policy-ben. a gyakorlatban siman elofordulhat, hogy ennel sokkal finomabb szabalyozasra van szukseg (elarulom, hogy ez a gyakoribb ;-). pl. X felhasznalo nem torolhet le bizonyos altala letrehozott file-okat, mert a ceges audit policy eloirja ezt. hogyan tudnam ezt en, a programozo elore? sehogy. erted mar, miert nem a programozo feladata policy-t gyartani?

"keverni akkor tudnam oket, ha ismernem a *te* definicioidat rajuk. hajra, ne tartsd vissza ;-). addig is:"

tolem nevezheted eroforrasnak, csak ne felejtsd el hogy a rendszer mukodesebol adodoan ez nem ugyanolyan "eroforras" mint pl az unlink().

"a legelso hosszaszolasod elso ket mondatabol az kovetkezik, hogy mivel (szerinted) a program iroja ismeri a programja altal igenyelt 'eroforrasokat', ezert neki kene szallitania a policy-t. a kesobbi (kulonosen az utolso) hosszaszolasod alapjan ugy tunik, hogy te nem tudod, mi az a policy, mi celt szolgal, es ezert kotod az ebet a karohoz."

tobb mint 4 eve irok RSBAC policykat, korlatozom benne hogy a program milyen eroforrasokhoz fer hozza. es mukodik. de hivjuk eroforras definialo filenek ha jobban tetszik. a problemam - ami miatt azt irtam hogy a program irojanak kellene szallitania a policy filet - az az hogy en nem fogom a program forraskodjat vegignezni hogy ugyan milyen eroforrasokra van szuksege, ezert marad a teszteles. eloszor elkezdjuk futtatni a programot egy olyan minimalis eroforrassal amire biztosan szuksege van, majd - mivel a rendszer logolja hogy milyen eroforrasok hasznalatat tiltotta meg a programnak futasa soran - ez t bovitjuk addig amig a program megfeleloen mukodik. de kinek van ideje kitesztelni egy program osszes eroforras szuksegletet? a program iroja viszont tudja azt hogy milyen eroforrasokhoz akar a programja hozzaferni igy o tudja legpontosabban megmondani hogy milyen eroforrasok hasznalatat kell engedelyezni a program szamara.

"akkor megegyszer: egy MAC policy *NEM* a programok viselkedeset irja le"

ezt nem tudom kinek magyarazod, senki nam allitott ilyent. legalabb is en biztosan nem tudnek rola. en azt mondtam hogy a policy a program futasahoz szukseges eroforrasokat irja le.

"amiert te valoszinuleg felreertetted a policy szerepet az az, hogy amikor megnezel egyet, akkor azt latod, hogy tele van ilyesmikkel:"

en nem neztem meg egyetlen olyan filet sem ami tele lenne ilyesmikkel, viszont ilyenekkel igen:

""
"0.0.0.0"
(allow-dev-read
allow-dev-write
allow-external-ipc)
(setgid
setuid
net-bind-service
kill)
(sysctl)
(rlimit)

ha itt nincs pl. setgid akkor a program nem tudja hasznalni a setgid eroforrast. ettol vagy elhasal vagy nem. mivel a program iroja irta bele a programjaba a setgid-et, hadd ne en talalgassam mar hogy kell-e a programnak vagy sem, szallitsa o policyt.

"ebbol azt a kovetkeztetest vontad le, hogy akkor lam, a policy azt irja le, hogy mire van szuksege az adott programnak. ez a tevedes! a policy itt is azt irja le, hogy az adott 'felhasznalo' mit fogad el biztonsagi kockazatkent"

a biztonsagi kockazat ez:

"Az ilyen támadásokból adódó fenyegetés abban rejlik, hogy a támadó rossz esetben rá tudja venni az alkalmazást olyan viselkedésre, ami tőle váratlan és nemkívánatos"

tehat a varatlan es nem kivanatos viselkedes a kockazat, amit a keretrendszer meg tud akadalyozni ha tudja hogy milyen eroforrasok hasznalata nem az.

"az unlink-es peldamra visszaterve: az edeskeves, hogy te engedelyezed az unlink 'eroforras' hasznalatat a policy-ben. a gyakorlatban siman elofordulhat, hogy ennel sokkal finomabb szabalyozasra van szukseg pl. X felhasznalo nem torolhet le bizonyos altala letrehozott file-okat, mert a ceges audit policy eloirja ezt. hogyan tudnam ezt en, a programozo elore? sehogy."

ennek mar semmi koze a program mukodesehez szukseges eroforrasokhoz, nem a program policyjaban kell meghatarozni.

"erted mar, miert nem a programozo feladata policy-t gyartani?"

szerintem nem igy van :)

( gd | 2007. 11. 09., p – 22:16 )

"Manipulating AppArmor policy requires being both root privileged
and not being confined by AppArmor, thus there is explicitly no
capability for non-privileged users to change AppArmor policy."

Van olyan biztonsági rendszer, amiben nincs ez a korlát? Azaz amivel mint mezei felhasználó, az általam futtatott programoknak további korlátozásokat szabhatok meg, hogy azok a saját fájljaimhoz se férhessenek hozzá, ha nem szükséges?

( nevergone v | 2007. 11. 09., p – 23:53 )

Jó dolog (lehet), csak kellene hozzá valami érthető leírás... esetleg valami segédprogram a kezdeti használathoz. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( gee v | 2007. 11. 10., szo – 10:50 )

És van-e vajon valami olyan, egyszerű nyelvezettel írt leírás, ami alapján az ember ki tudja találni, hogy mi az, amit viszonylag egyszerűen tud használatba venni, de ugyanakkor hatékony is?

Olyasmire gondolok, hogy mondjuk olvastam technikai leírásokat, vagy tervezési papírokat, vagy mi a fene, (illetve ezekből mazsolázott valaki), és ennek alapján pl. a SELinux nekem nem tetszik. De hogy használni milyen, arról fogalmam sincs.
Az RSBAC meg pl. tökre tetszik, de beállítani...
És akkor még van számos ehhez hasonló megoldás, ugye.

Szóval valami olyan összehasonlítás van-e, hogy X terméket baromi könnyű beállítani, mert pl. bekapcsolom a tanuló módot, és csak használom a gépet egy napig, Y terméket kicsit nehézkes, mert egy felületen kell klikkelgetni, mindent jól átgondolva, Z terméket meg baromi nehéz.
Y termék védelme kiterjed erre, erre és erre, van benne ez és ez, és van más, ami viszont nem tűnik valami jó megvalósításnak, vagy még ez és az a hiba/probléma/szempont lehet.
Z termék...
X termék...

Szóval ami alapján azt mondhatja az egyszerű rendszergazda, hogy a védelem és használhatóság szempontjait figyelembevéve tud választani

G

Hát én az apparmort ismerem valamennyire.

Abban van "tanuló" mód aminek segítségével elég jól végigkövethető, hogy az általad kontrollálni kívánt alkalmazás hova nyúlkál, és milyen erőforrásokhoz fér hozzá.
Szvsz a beállítása nagyon egyszerű. Akár parancssori, akár grafikus beállítási módot használsz, néhány perc alatt meg lehet csinálni.
A LOK2007 konferencián volt egy bemutatója az apparmornak, a gyakorlatbna is megnéztük egy ilyn policy beállítását, tényleg nem volt nagy kunszt. Elvileg a video fent van valahol asszem.