Kernel-based security hardening

[Verwijderd]

Wat is jullie mening hierover? Is het sop de kool waard? Wat zijn jullie bevindingen ermee?

Papillon. Een Solaris 8.0 security module a-la Openwall/HAP/GrSecurity/Stephanie etcetera! Voor i386/sparc Is er iemand die deze al geprobeerd heeft? Ik zit er over te denken deze volgende week eens te testen.

Links naar de projecten staan erin. Eerst goed lezen. Stephanie is niet stable; sommige features zijn niet bruikbaar. Als er iemand nog andere links heeft: graag

[Verwijderd]

http://www.nsa.gov/selinux/
Dat is wel de meest dubieuze overigens. De US overheid en beveiliging van OSsen. Maar het is open source dus eventuele backdoors zouden dan relatief eenvoudig op te sporen moeten zijn.

Zelf (nog) geen ervaring met een security enhanced kernel, als ik er een zou kiezen zou het denk ik GrSecurity zijn.

[Verwijderd]

Eerste stap die je zou kunnen nemen zonder patches te installeren. Geen kernel modules gebruiken, maar alles direct in de kernel compilen. Veel rootkits tegenwoordig zijn kernel modules en die kun je dan niet meer installeren.

Je hebt ook rootkits die zich direct in het geheugen nestellen. Die kun je dus nog steeds installeren op een systeem zonder kernel modules. Ik heb wel eens wat patches gezien om te voorkomen dat elk proces direct naar het geheugen kan schrijven, maar kan ze niet meer vinden.

[Verwijderd]

Verwijderd schreef op 07 september 2002 @ 12:30:
Eerste stap die je zou kunnen nemen zonder patches te installeren. Geen kernel modules gebruiken, maar alles direct in de kernel compilen. Veel rootkits tegenwoordig zijn kernel modules en die kun je dan niet meer installeren.

Je hebt ook rootkits die zich direct in het geheugen nestellen. Die kun je dus nog steeds installeren op een systeem zonder kernel modules. Ik heb wel eens wat patches gezien om te voorkomen dat elk proces direct naar het geheugen kan schrijven, maar kan ze niet meer vinden.

Dat tweede geeft aan waarom dat eerste eigenlijk niet meer echt veel uitmaakt. Daarom zullen (afaik) in 2.6.x of 2.7.x modules niet meer uitgeschakeld kunnen worden en zullen alle drivers altijd modules worden en niet meer in-kernel gecompiled kunnen worden.

(bron: Alan Cox op linux-kernel, half jaar geleden oid)

[igmar]

Verwijderd schreef op 07 september 2002 @ 12:55:
Dat tweede geeft aan waarom dat eerste eigenlijk niet meer echt veel uitmaakt. Daarom zullen (afaik) in 2.6.x of 2.7.x modules niet meer uitgeschakeld kunnen worden en zullen alle drivers altijd modules worden en niet meer in-kernel gecompiled kunnen worden.

(bron: Alan Cox op linux-kernel, half jaar geleden oid)

Ik moet dit eerst nog zien eerlijk gezegd. Het tweede probleem is betrekkelijk simpel door /dev/kmem read-only te maken, wat mogelijk is met grsec.

Dat driver standaard modules worden twijfel ik zeer aan, geen toegevoegde waarde, en je moet dat met initrd gaan werken. Niet echt een optie in de meeste gevallen.

[Verwijderd]

Verwijderd schreef op 07 september 2002 @ 12:55:
[...]


Dat tweede geeft aan waarom dat eerste eigenlijk niet meer echt veel uitmaakt. Daarom zullen (afaik) in 2.6.x of 2.7.x modules niet meer uitgeschakeld kunnen worden en zullen alle drivers altijd modules worden en niet meer in-kernel gecompiled kunnen worden.

(bron: Alan Cox op linux-kernel, half jaar geleden oid)

Het overgrote deel van de rootkits wat je in het wild aantreft zijn nog steeds linux kernel modules. Je stopt hier dus wel een groot deel van de rootkits mee en daarmee ook een groot deel van de niet zo ervaren crackers.

De reden waarom ik ook het voorbeeld gaf van rootkits die direct naar het geheugen schrijven is om ook aan te geven dat je niet alleen op een kernel zonder kernel modules moet vertrouwen. Zoals Igmar al aangeeft zijn er dus patches om /dev/kmen read only te maken.

100% security bestaat zowiezo niet, maar het is wel weer een extra verdedigingslaag waar je een deel van de crackers mee stopt. Wie garandeert bijvoorbeeld dat al die security patches geen fouten bevatten.