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õ
Hozzászólások
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
(toroltem)
"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.
törölve, write-only-ban voltam :D
altalaban minden csomagkezelo hasznal sumokat. meg ha nem is van benne erre a checkolasra kulon opcio, akkor is konnyen scriptelheto.
--
elkuldtem a jelentkezest, mert ez atema erdekel. varom a valaszt. udv.
>altalaban minden csomagkezelo hasznal sumokat. meg ha nem is van benne erre a checkolasra kulon opcio, akkor is konnyen scriptelheto.
jaja, mindenhol ot van de nincs egybe gyúrva.
>elkuldtem a jelentkezest, mert ez atema erdekel. varom a valaszt. udv.
okés :)
> ez kb. mar minden csomagkezeloben meg talalhato
De ahol nincs meg, az ott még jó szakdolgozat lehet :)
És mi a helyzet, ott ahol megvan?
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.
ez nem az amit ok akarnak. mindeki hulye?! policy alapu kell.
up