Új (utolsó?) grsecurity kiadás és fontos bejelentés

trey, médium még nem vagyok, nem tudom megmondani, hogy mennyi az annyi. de mindenképp több emberhez jutna el / több ember használná, ez szerintem 100%, akármeddig filozofálunk rajta :)

Ha én disztrót állítanék össze, inkább az alap kernelben lenne a grsec, és lenne alternatív kernel, virtualizációs host-nak.

Nem tudom, mennyire gyakori, hogy az emberek virtualizációt használjanak. Van haverom, aki olyan helyen dolgozik, ahol vmware-re alapozva dolgoznak nagy infrastruktúrával... gondolom nekik nem lenne gond telepítéskor feltenni egy másik kernelt, hisz az egész infrastruktúrát jól megtervezték.

Desktopon vajon hányan használnak virtualizációt, és milyen gyakran? Én 98-ban rendszeresen futtattam linux hoston windowst vmware-rel, aztán évekig nem. Épp a napokban tettem fel egyet, mert meguntam, hogy az XP-t nehéz telepíteni (SATA driver miatt, nLite akármi valahogy félresikerült, mindegy).
Baromi ritkán használom, van egy banki szoftver, amihez szoktam, meg abev, meg nyenyi, meg office (ritkán), még egy valami, ami most nem jut eszembe...
Mondjuk elindítom két hetente egyszer? Vagy havonta egyszer?

Inkább grsec-et választanék állandóra, legfeljebb ha bevallani akarnék, vagy utalni a bankban, akkor reggel a másik kernelt indítanám (ahogy korábban a külön partícióra tett windows-t indítottam, ritkán).

A szervereimen (most 3 darab van) virtualizációt nem használok, viszont grsec-et igen.

Tudom, ez én vagyok, lehet, hogy másnak tök mások az igényei, de én úgy gondolom, hogy azok a gépek, amik virtualizációt használnak folyamatosan (vagy gyakran), kevesebben lehetnek, mint azok, amik nem.

+1: ha benne lenne a vanilla kernelben, talán a virtualizációs technológiák gyártói is ráállnának, hogy megkeressék az inkompatibilitás okát, és elhárítsák az akadályt a grsec alatt futtatott vmware, vagy akármi más elől.

G

Ez osszehasonlitas volt, tudod, amikor ket kulonbozo dolog kozott elmondjuk, hogy mik a hasonlosagok vagy kulonbsegek

Ezesetben is él és továbbra is igaz a válaszom, miszerint sokkal könyebb a beállítása a grsec/RBAC-nak, mint az RSBAC-nak, amelyet ezekszerint összehasonlítás céljából hoztál fel.

Az más kérdés, hogy RSBAC nyilván nagyon sok plusz dolgot is támogat, amelyet az RBAC nem. (Ha valakinek sikerült már megvalósítani vele egy 100%-osan megfelelő La Padula modellt, amelyet gyakran emlegetnek érvként, az szóljon...)

A PAX_UDEREF eleg hulye pelda, hiszen az userland-en belul fejti ki hatasat, nem pedig a kernelterben, es a modulok kozt, mint azt a grsec teszi.

Huh. Nem. UDEREF a kernel->userland hivatkozásnál fejti ki hatását. A grsec pedig nem csinál semmit a modulok közt. :) Mind1. Mondandóm lényege az volt, hogy rengeteg olyan funkció került már be a kernelbe, amelyik egy másikat befolyásol.

Arra gondoltam, hogy mivel a grsec jelenleg a kernelen belul is inkompatibilitasokat okoz bizonyos nepszeru 3rdparty modulok hasznalatanak ellehetetlenitese miatt, igy az a disztrokban nem terjesztheto default disztrokernelkent, csak mint kulon csomagolt kernel.

Mmm. Megint csak azt tudom mondani, hogy rengeteg olyan dolog van a mainline kernelben, amelyet a disztrokernelek nem használnak, be sem fordítanak a saját kerneleikbe. Ezt sem lenne kötelező bekapcsolni/használni alapból, így továbbra sem érv ez a bekerülése ellen.

Csak ha uj szolgaltatas kerul fel, akkor ujra learning mod?

Nyilván úgy érdemes csinálni, hogy egy teszt rendszeren a bevezetésre kerülő szolgáltatásról csinálsz learning-mode segítségével egy hozzá tartozó policy filet és azt átemeled az éles rendszerbe a bevezetés során.

Mennyire egyszeru benne olyasmit beallitani amit a learning mod esetlegesen nem megfeleloen ismert fel, vagy picit bonyolultabb a beallitasa?

A grsec audit funkcióival elég gyorsan kideríthetők az esetleges problémák, amelyeket egy túl szigorú policy idéz elő. Ez learning-mode esetén ritkábban fordul elő, akkor valószínűbb, ha valaki kézzel módosítja utólag a policy filet vagy valamit változtat a szolgáltatáson.

Mellesleg ugy erzem, jogom van akkor es arrol irni, amikor es amirol szeretnek

Ez így van, csak egyrészről magadat járatod le vele, ha olyan témában nyilatkozol komolyan, amelyhez nem értesz, másrészről hiteltelenné válhatsz és utána más témák esetén sem vesz majd senki komolyan.

Elnézést. Kérdezni szabad? Vagy akkora sztár ez a biztonsági megoldás, hogy be kell jelentkezni audienciára.

Ne ferdíts, nem kérdések hangzottak el, nem azokkal voltak problémák.

Az a kicsit sem lekezelő, kicsit sem flegma, kicsit sem arrogáns stílus, amely körülveszi ezt az egészet teszi olyan kedvessé számomra ezt a projektet.

2 napja van kinn a cikk és eddig nem szóltam hozzá, de ennyi összehordott badarságra úgy éreztem valakinek reagálni kell, függetlenül attól, hogy nekem nem tisztem a projekt megvédése.

(Persze nyilván tudom, hogy neked csak azért szálka a szemedben ez a biztonsági megoldás, mert az egyik fejlesztőjével való szakmai vitádban súlyos módon besültél... Mások azért ezt képesek ám intelligensebben is lekezelni. ;)

Igen, de a célközönség nem a desktoplinuxpistikék közül kerül ki, mint ahogy nem nagyon hallani pl. OpenSSH- vagy Apache-beállító GUI-ról sem.
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"