Szabad diploma : apt-get securityaudit

Szabad diploma

Kedves Kollégák,

Mellékelve küldöm az első szabad diploma tervet, a szöveg természetesen alakítható. jelentkezéseket az FSF-hez (csaba.erdei at fsf dot hu) és hozzánk (zsolt.farkas at puli dot co dot hu) is el lehet juttatni. Visszajelzéseket, véleményeket is várok!

Az FSF alapítvány és cégünk, a PULI Mérnöki Tanácsadó, Kereskedelmi és Szolgáltató Bt. nyílt forráskódú diplomaterv (szakdolgozat) tervet ír ki az alábbi témá(k)ban, Linux, Unix rendszerekhez, 1-2 fõ részére a 2006-2007-es tanév õszi félévében.

Tárgy: nyílt forráskódú diplomaterv (szakdolgozat) kiírás, apt-get securityaudit

A probléma ismertetése: A telepített Unix, Linux rendszerek integritás ellenõrzése mindig is fontos kérdés volt, és jelenleg is az. A megvalósított integritás ellenõrzõ rendszerek (Tripwire, Integrit, Audit, Aide, stb.) rengeteg problémával küzdenek, hiszen ezek a rendszerek saját adatbázisba mentik el a telepített komponensek adatai (dátum, méret, tulajdonos, jogosultságok, stb.) melyet rendszeresen frissíteni és állandóan védeni kell. Jogosan vetõdik fel az a kérdés, hogy szükség van e külön adatbázisra, mikor ezek az adatok az operációs rendszer repository-jában megtalálhatóak, és onnan (részben) kinyerhetõek, tehát az integritás ellenõrzési folyamat legcélszerûbben a csomagkezelõ rendszerbõl végezhetõ el. Utóbbi esetben feltételezzük, hogy a repositoyban található adatok mindig autentikusnak, és (kvázi egyirányú) kommunikációval mindig kinyerhetõek.

Feladat: Bõvítse ki az apt csomagkezelõ rendszert a telepített csomagok integritás ellenõrzésével, a megvalósítás jelezze ha egy vagy több adott fájl mérete, dátuma, ellenõrzõ összege, tulajdonosa eltér attól ami a repositoryban elhelyezett fájlokban található. A megvalósítás legyen képes súlyozni a problémákat, pl.
egy bináris fájl eltérése a /bin alatt súlyos,
egy konfigurációs fájl eltérése a /etc alatt átlagos,
egy nem csomagból származó saját fájl a /home alatt szokványos, de
egy 777 jogú fájl a /home alatt fontos hibának számít.

Természetesen lehetõség van az implementációt más rendszeren is megcsinálni (BSD, RH), értelem szerûen a rendszer saját csomagkezelõjét felhasználva.

Hasonló, részleges implementációk:
rpm -Va rpm repository alapján a telepített csomagok integritás vizsgálta, nem vizsgálja a forrásból telepített komponenseket, a lista nehezen áttekinthetõ
debsums -s deb repostory alapján telepített csomagok integritás vizsgálta, a hiányzó ellenõrzõ összegû csomagok megjelenítése, de a lista részleges és nehezen áttekinthetõ

( thuglife | 2006. 10. 03., k – 13:22 )

ez kb. mar minden csomagkezeloben meg talalhato. BSD-k eseteben csak 3rd party programok vannak csomagkezelovel feltelpitve tehat csak ezekrol van a package databaseben md5 sum (a csomagban levo osszes filerol).
Az hogy a base rendszerhez tartozo fileok milyen checksummal rendelkeznek nagyon sok esetben szinte meghatarozhatatlan lesz, mivel a NetBSD és FreeBSD felhasználóknak az a mániája, hogy ujraforidtjak a rendszeruket. Igy termeszetesen mar egytalalan nem fog megyezni egy csomo checksum a mondjuk hivatalos kiadassal. OpenBSD ben azert tobben kezdenek mar szerencsere leszokni errol es binaris csomagokat hasznalni, mind az alaprendszer telepitesehez es frissitesehez mind a 3rd party csomagok telepitesehez. Tehat igy hogy a felhasznalok nagy resze mindig forditgat eleg nehez egy kozponti checksum adatbazisra tamaszkodni.
Persze az is megoldas, hogy minden ujraperdites utan ujrachecksumoljuk az osszes filet.

Ujra felmerul a kerdes. Penzugyek? Stb? En szivesen foglalkozom ilyesmivel de azert ennek kicsit tobb info kene.

>ez kb. mar minden csomagkezeloben meg talalhato

Igen? Konkrétan melyikben? Csak kérdem, mert én nem tudok róla.

>az a mániája, hogy ujraforidtjak a rendszeruket. Igy termeszetesen mar egytalalan nem fog megyezni egy csomo checksum

Hja, de nem erről van szól, illetve a feladat nem erről szól.
Van egy stable/testing/unstable (/volatile/backport/stb.) csomagok tetszőleges kombinációjából összeállított rendszer, a feladat az, hogy az eredeti csomagokal kell öszehasonlítani ez aktuális állapotot.

>Ujra felmerul a kerdes. Penzugyek? Stb?

ld. másik témánál, bővebben

"Igen? Konkrétan melyikben? Csak kérdem, mert én nem tudok róla."

pl:
Solaris, pkgchk parancs.

"tehát az integritás ellenõrzési folyamat legcélszerûbben a csomagkezelõ rendszerbõl végezhetõ el. Utóbbi esetben feltételezzük, hogy a repositoyban található adatok mindig autentikusnak"

Khm, az integritás ellenörzésnél alapvető, hogy csak olyan forrásban bízunk meg, ami garantáltan(!) nem módosítható. Tehát pl. egy tripwire adatbázis CD-romra írva megfelelő, de egy tripwire adatbázis lokálisan file-rendszerben tárolva már nem.
Csomagkezelő rendszerből vett adatoknak alapvetően a konfigurációs fájlok és a logfájlok a gyenge pontjai, valamint a felhasználói adatok.
Pl. egy webszerveren érdemes a tartalmat is checksum-olni.

Úgy gondolom a csomagkezelő rendszer által nyilvántartott fájl-adatok csak kiegészítések lehetnek egy tripwire jellegű rendszer mellett. Továbbá lehetőséget kellene biztosítania a checksum-ok, egy globális repository-val történő összehasonlítására, ezzel is csökkentve a helyi manipulálás lehetőségét.

itt most nem csak 3rd party csomagokrol lenne szo, hanem full rendszerekrol es amelle policy irasarol. ergo egy Symantec ESM 1-2 hasonlo funkciojara.
a checksum adatbazisnak mindenkeppen tobb es megbizhato helyen kell meglennie. sok fajta implementalasi mod van. ez attol fugg hogy ki csinalja.

>pl:
>Solaris, pkgchk parancs.

Ha jól olvasom a manját, ez is csak hasonló.
pl kapásból csak egy csomagról/könyvtárról tudja megmondni, ogy stimmelnek-e az összegek vagy sem

>Khm, az integritás ellenörzésnél alapvető, hogy csak olyan forrásban >bízunk meg, ami garantáltan(!) nem módosítható.

Triviális, nyilvánvaló állítás.

>Tehát pl. egy tripwire adatbázis CD-romra írva megfelelő, de egy tripwire >adatbázis lokálisan file-rendszerben tárolva már nem.

Épp ezért nem is tudok ideálisabb helyet a "tripwire adatbázis" (nevezzük checksum adatbázisnak) számára mint mondjuk a security.debian.org
CD-re meg az írja ki aki ráér. Minden egyes update, upgrade után Tripwire update, majd CD-re írás? Kicsit macerás, nem?

>Csomagkezelő rendszerből vett adatoknak alapvetően a konfigurációs >fájlok és a logfájlok a gyenge pontjai, valamint a felhasználói adatok.

Ezen el lehet gondolkozni, de már a diplomaterven belül. pl minden az apt-get securityaudit előtt ellenőrizni kell, hogy az apt-get mérete, dátuma, md5-je ennyi meg ennyi. A config fájl így meg így néz ki.Ha nem, akkor azt is megpatkolták, leht aggódni.

>Úgy gondolom a csomagkezelő rendszer által nyilvántartott fájl-adatok >csak kiegészítések lehetnek egy tripwire jellegű rendszer mellett. >Továbbá lehetőséget kellene biztosítania a checksum-ok, egy globális >repository-val történő összehasonlítására, ezzel is csökkentve a helyi >manipulálás lehetőségét.

Nagyjából pont erről van szó. A repositoriban már úgyis tárolódik csomó minden, hiszen amikor telepítesz egy csomagot adott rendszeredben adott helye, adott méretű, jogú, tulajdonosú fájlok keletkeznek. Innen már csak egy lépés, hogy a telepített fájlokat összehasonlítsuk a csomag eredeti tartalmával.

És mi a helyzet, ott ahol megvan? 

$ apt-cache show debsums
Package: debsums
...
Description: Verify installed package files against MD5 checksums.
 debsums can verify the integrity of installed package files against
 MD5 checksums installed by the package, or generated from a .deb
 archive.

Tényleg nem kötekedni akarok, de mielőtt valaki hozzászólna, illendő lenne, hogy elolvassa a témakiírást.

Ha elolvassa és eljut eddig a pontig:
Hasonló, részleges implementációk:
...
debsums -s deb repostory alapján telepített csomagok integritás vizsgálta, a hiányzó ellenõrzõ összegû csomagok megjelenítése, de a lista részleges és nehezen áttekinthetõ

akkor már választ is kapott a kérdésére.