[Disc] Is een kleinere kernel ook een veiligere kernel?

[Verwijderd]

daft_dutch schreef op dinsdag 11 oktober 2005 @ 02:57:
iedereen die een kernel compileert houdt zich er wel mee bezig met de vraag hoe klein kan mijn kernel zijn. kleiner = minder fouten = minder kans dat een 3v1l cracker root kan krijgen.
[...]

Met alle respect vriend, maar waarop baseer je dat verhaal? Je kun een nog zo kleine kernel maken, als er maar 1 driver tussenzit die sploitbaar is, dan is dit hele bovenstaande verhaal void. Als je geen netwerkkabel in je box steekt, of m uberhaupt niet aanzet, dan heb je nog minder kans om een "3v1l" cracker op je machine te krijgen...

Enable loadable module support? Hell no

Voor servers is dit goed te doen, en voor hele kritieke statische systemen zelfs aan te raden. Echter, als je dit ook op de desktop gaat toepassen, dan schiet je jezelf een btje in je voet als je niet bereid bent _veel_ tijd te steken in het goed configureren van je kernel. Tijd die de meeste van ons niet hebben of willen vrijmaken. De gemiddelde desktop (KDE/Gnome), maakt tegenwoordig driftig gebruik van de nieuwe mogelijkheden die de kernel met zich meebrengt, (sysfs met daarbij hal/udev en loadable module support), zodat je een goeie "desktop" experience krijgt.

Als je zo gefocust bent op het weren van "3v1l" crackers, waarom draai je dan niet een OS wat gemaakt is om opgewassen te zijn tegen dit soort typen... **kuch** OpenBSD **kuch**. Kijk. Je kunt de security van je OS met een magnitude vergroten, door gebruik te maken van een ander OS (liefst op niet x86 hw). Waarom? Omdat de meeste sploits geschreven zijn voor een bepaald OS (Windows / Linux) werken deze meestal niet out-of-the-box op systemen die niet in dat lijstje staan. (Afwijkende geheugen offset's, non-executable stacks, totaal andere memory layout, ander binair formaat om maar ff een aantal voordelen te noemen).

Persoonlijk vind ik dat veel betere security dan de grootte van m'n kernel

[0siris]

daft_dutch schreef op dinsdag 11 oktober 2005 @ 02:57:
kleiner = minder fouten = minder kans dat een 3v1l cracker root kan krijgen.

Da's wel héél kort door de bocht

0bits/bytes what ever

Tja, ALS het je dan zoveel uitmaakt hoe groot je kernel is, lijkt het me zinvol te weten of dat wat weergegeven wordt, uitgedrukt wordt in bits of bytes.

Enable loadable module support? Hell no

Dat juist handig, zeker als je over beveiliging denkt zoals jij volgens mij denkt: Op deze manier kun je support voor dingen die je anders statisch in de kernel zou compileren, op bevel toevoegen en verwijderen.
_{Mijn kernel (2.6.11) is overigens 1991287 bytes groot}

[ Voor 6% gewijzigd door 0siris op 11-10-2005 10:42 ]

[daft_dutch]

0siris schreef op dinsdag 11 oktober 2005 @ 10:39:
Da's wel héél kort door de bocht

Nu ik het terug lees is het inderdaad kort door de bocht kom dronken thuis, pc stond nog aan op NOS en van het een komt het ander.

Tja, ALS het je dan zoveel uitmaakt hoe groot je kernel is, lijkt het me zinvol te weten of dat wat weergegeven wordt, uitgedrukt wordt in bits of bytes.

standaard notatie
KB is kilo bytes
Kb is kilo bits

<quote daft>Enable loadable module support? Hell no :p</quote>
Dat juist handig, zeker als je over beveiliging denkt zoals jij volgens mij denkt: Op deze manier kun je support voor dingen die je anders statisch in de kernel zou compileren, op bevel toevoegen en verwijderen.

meningen verschillen veel wormen/virusen gebruiken root kits en rootkits passen vaak modules aan of maken er zelf een om de content van de worm uit te voeren. Natuurlijk is de worm al binnen op mijn server maar de kans is verkleint dat mijn server andere pc's mee lastig gaat vallen.

daarbij ik was vergeten dat het een servertje is ik kloot er niet veel mee. De pc staat in een kruip ruimte van alles en iedereen verlaten.

[edit]
alles wat je altijd gebruikt in de kernel is gewoon sneller.
leuk voorbeeld:
De windows NT kernel is een micro kernel. maar ze hebben heel veel modules toch maar in de kernel gecompileert omdat deze anders te traag was.

[ Voor 15% gewijzigd door daft_dutch op 11-10-2005 15:40 ]

[Verwijderd]

daft_dutch schreef op dinsdag 11 oktober 2005 @ 02:57:
iedereen die een kernel compileert houdt zich er wel mee bezig met de vraag hoe klein kan mijn kernel zijn. kleiner = minder fouten = minder kans dat een 3v1l cracker root kan krijgen.

uname -r: 2.6.8

regels config: 184
vmlinuz: 1.8MB
System.map: 684KB

du -ch /lib/modules/<kernel>: 0bits/bytes what ever

opmerkingen:
Enable loadable module support? Hell no

edit:
dit is mijn servertje mijn desktop heeft wel modules (de nvidia driver en een paar experimentele dingen)

Als je begaan bent met security, waarom draai je dan zo'n antieke kernel?
Hopelijk heb je de security patches applied?

[zomertje]

Afgesplitst uit: 'Hoe klein is jouw kernel'

Dit kan een leuke discussie worden. Geflame is echter niet gewenst.

Ontopic: Minder code geeft minder fouten en zou dus leiden tot minder exploits. Veel kleine programma's zijn voor een programmeur overzichtelijk, en zo kan de kans op fouten ook kleiner zijn. Maar het blijft natuurlijk theorie en ook een kleine kernel kan niet goed zijn of een grote juist wel

[moto-moi]

zomertje schreef op woensdag 12 oktober 2005 @ 20:44:
Minder code geeft minder fouten en zou dus leiden tot minder exploits. Veel kleine programma's zijn voor een programmeur overzichtelijk, en zo kan de kans op fouten ook kleiner zijn.

Klopt, maar de kernel is geen klein programma, het is ruim 200MB groot

Maar het blijft natuurlijk theorie en ook een kleine kernel kan niet goed zijn of een grote juist wel

Nou, op zich zit er wel een kern van waarheid in, hoe minder code je gebruikt uit een groot project, des te kleiner is de kans dat er een exploit inzit.
Alleen zijn er bepaalde gedeelten van de code die je altijd zal moeten gebruiken hetgeen dus procentueel meer kans oplevert dat er een exploit voor is.
Tenslotte, een obscure driver die je gebruikt zal niet snel gehacked worden, puur omdat die code niet vaak gebruikt wordt

Als ik terugdenk aan Fosdem van dit jaar, waar Alan Cox himself zei dat hij niet aan de tty code durfde te komen omdat hij de ervaring had dat dat gedeelte van de code zo verweven was met de rest.
Tsja, dan is een 'simpele' exploit van die oude code (Alan had het over pre 0.99 ) een zeer groot gevaar.

[Varienaja]

Volgens mij is er geen evenredig verband tussen aantal regels code en kwaliteit van die code. Daarmee wil ik zeggen dat kleine programma's niet noodzakelijk minder buggy zijn dan grote.

Ik weet als ontwikkelaar heus wel dat je 'ervanuit kunt gaan' dat je per 10 regels code 1 fout hebt. Maar het onderliggende ontwerp, de samenwerking tussen ontwikkelaars, de kwaliteit en de code-coverage van je tests maken veel meer uit voor de uiteindelijke kwaliteit.

Een fout is een fout, maar een schrijffout in een menu-item is natuurlijk heeft natuurlijk een heel andere invloed op de kwaliteit als een algoritme dat in een oneindige loop kan gaan blijven hangen. Dit verhaal geldt is voornamelijk gebaseerd op 'normale' software, maar gaat ook op voor kernels. Da's tenslotte ook software.

[Guru Evi]

Ik heb alles IN mijn kernel gecompileerd ipv als modules op een redelijk uitgebreide laptop. Dus hier komt mijn grootte (niet verschieten):2.6M
Daar zit wel exact alles in wat er in de laptop zit hardwarematig zonder enige andere zaken en de softwarefuncties die ik regelmatig gebruik (dus processor, processorfuncties, powermanagement, acpi, verschillende soorten lan, pcmcia, poorten, drives, fs's, usb, firewire, ipv4, ipv6, pppoe etc.). De apparaten die ik "hotplug" of niet onderdeel zijn van de pc zelf zet ik als module.

Waarom: snelheid. Het opstarten duurt wel iets langer maar dat doe je maar 1x, de rest staat in standby en dan moet je dat niet meer doen maar ik heb het gevoel dat het iets sneller werkt

Op mijn ander systeem heb ik dan een kernel van 1,5M. Daar zit dan alles in die nodig is om een systeem op te starten (met verschillende hardware en bestandssystemen) maar omdat de hardware nogal eens verandert (netwerk, videokaarten etc.) zet ik de rest erin als module.

Op mijn colocated server heb ik zelfs geen loadable modules omdat rootkits enzo deze kunnen gebruiken. Het is ook niet nodig om elke week de kernel te hercompileren omdat er een nieuwe is, je neemt een stabiele, compileert die en laat die voor maanden draaien. Alle hardware die ik nodig heb zit in de kernel (net, disc, lan, video), de rest is eruit gekieperd (geen USB, firewire, ipv6 of andere zooi die je in een cabinet toch niet van doen hebt).

[zomertje]

moto-moi schreef op woensdag 12 oktober 2005 @ 20:55:
[...]

Klopt, maar de kernel is geen klein programma, het is ruim 200MB groot

Tenzij je hem klein maakt

Nou, op zich zit er wel een kern van waarheid in, hoe minder code je gebruikt uit een groot project, des te kleiner is de kans dat er een exploit inzit.
Alleen zijn er bepaalde gedeelten van de code die je altijd zal moeten gebruiken hetgeen dus procentueel meer kans oplevert dat er een exploit voor is.
Tenslotte, een obscure driver die je gebruikt zal niet snel gehacked worden, puur omdat die code niet vaak gebruikt wordt

Als ik terugdenk aan Fosdem van dit jaar, waar Alan Cox himself zei dat hij niet aan de tty code durfde te komen omdat hij de ervaring had dat dat gedeelte van de code zo verweven was met de rest.
Tsja, dan is een 'simpele' exploit van die oude code (Alan had het over pre 0.99 ) een zeer groot gevaar.

Grote projecten waar oude code en nieuwe verweven zitten zijn erg lastig. Dat zie ik op mn werk, er is niemand meer die alles weet of alles snapt. De oudste code is 12 tot 15 jaar oud en soms komen er dus verrassingen boven uit onverwachte hoek als men iets aanpast.

[Verwijderd]

Varienaja schreef op woensdag 12 oktober 2005 @ 20:58:
Volgens mij is er geen evenredig verband tussen aantal regels code en kwaliteit van die code. Daarmee wil ik zeggen dat kleine programma's niet noodzakelijk minder buggy zijn dan grote.

Ik zou wel durven beweren dat het doorgaans nadelig uitpakt voor grote kernels. Als je een hele kleine kernel hebt, dan is het veel makkelijker om (formeel) te bewijzen dat de gebruikte algoritmen juist zijn en dat er geen fouten kunnen optreden. Als je een grote hebt, dan moet je alle combinaties van drivers, die allemaal in de kernel space zitten, mee gaan nemen in zo'n test. Alleen al om te testen dat het niet voor kan komen dat een driver niet in een oneindige lus gaat. Stel je voor dat je alle drivers moet testen, op alle mogelijke manieren waarop die met elkaar verweven kunnen raken. Dat is véél lastiger bij een grote kernel.

Het aantal toestanden, situaties en mogelijkheden neemt doorgaans veel meer dan lineair toe met de lengte van de code. Als je dat dus van begin af aan voorkomt door de échte kernel klein te houden, dan scheelt dat behoorlijk. Performance is dan een tweede, maar dat is hier niet de halszaak. Bovengenoemd citaat van Alan Cox geeft al aan dat ook code de neiging heeft om te gaan klitten als je interfaces niet strict gescheiden houdt. Daarnaast, voor de meest basale kerneltaken, zijn er inmiddels vrij standaard algoritmen en door en door geteste stukken code, die denk ik een goede basis geven voor een vrij robuuste kernel.

[eghie]

Ik heb een 2 tal artikeltjes gevonden die over veiligheid gaat van onder andere de kernel met een aantal kernel modules: Why OpenBSD will never be as secure as Linux en z'n tegenhanger (van dezelfde gast) Why Linux will never be as secure as OpenBSD.

Nu staan er in dat artikel, waar Linux beter is, een aantal kernel modules in, die je beveiligen tegen een aantal zaken, zoals buffer overflows, stack overflows, etc.. Nu lijkt mij dat het veiliger is met die modules erin, dan dat je ze eruit laat. Zo zijn er nog wel een aantal kernel modules die voor veiligheid zorgen voor een aantal zaken, dus om zo maar elke kernel module eruit te halen wat je niet echt nodig hebt is niet echt veiliger.

Ik ben het wel eens met dat een kleinere kernel, minder kans heeft om fouten te bevatten, aangezien het ook minder code bevat. Maar hij heeft niet altijd alle beveiligingen die de kernel veiliger kunnen maken, dus het ligt er een beetje aan wat erin zit.

Ik vind het principe van, geen loadable modules gebruiken omdat die veel worden misbruikt door rootkits en dergelijke een goed iets. Ik weet niet hoeveel dit uitmaakt op de performance en op de onderhoud, maar je bent denk ik wel een stuk veiliger hiermee.

[DiedX]

Even voor de duidelijkheid:

Het is met een non-modulaire kernel nog steeds mogelijk om kernels (en dus ook exploits) te installeren. De exacte link staat op het internet, maar hier ook op GoT.

Je kan de grens dus HOGER leggen, maar dat is dan ook alles.

[eghie]

DiedX schreef op woensdag 12 oktober 2005 @ 22:11:
Even voor de duidelijkheid:

Het is met een non-modulaire kernel nog steeds mogelijk om kernels (en dus ook exploits) te installeren. De exacte link staat op het internet, maar hier ook op GoT.

Je kan de grens dus HOGER leggen, maar dat is dan ook alles.

Maar bij beveiliging zorg je ervoor dat je dus de drempel zo hoog mogelijk legt, maar wel dat je er zelf nog wel mee kunt werken.

[DiedX]

eghie schreef op woensdag 12 oktober 2005 @ 22:19:
[...]

Maar bij beveiliging zorg je ervoor dat je dus de drempel zo hoog mogelijk legt, maar wel dat je er zelf nog wel mee kunt werken.

1-0.

"There is no such thing as security". DiedX gaat in de hoek zitten

[Wilke]

Enable loadable module support? Hell no

Als je denkt dat dit veel uitmaakt, think again: Linux on-the-fly kernel patching without LKM. Dat het lastiger is dan even een module laden maakt ook slechts uit tot op het moment dat iemand een handig tooltje heeft geschreven om iets als bovenstaande te implementeren (op een makkelijk bruikbare manier).

Wat betreft aantallen bugs en grotere/kleinere kernels, het schijnt toch wel zo te zijn dat het aantal bugs per 1000 regels code in het algemeen redelijk constant is. In die zin zou het dus inderdaad wel te verwachten zijn dat in een kleinere kernel minder exploitbare fouten zitten. Het zou mij bijvoorbeeld niet verbazen als er bv. in de fs-driver voor iso9660 file systems (CD-ROM's) een foutje zou zitten. Dat is volgens mij zelfs wel eens voorgekomen - je zou dan met een speciaal geprepareerde CD met een precies op de juiste manier corrupted iso9660 FS wellicht de kernel kunnen overnemen.

Heb je die ISO9660 support helemaal niet in je kernel zitten, wordt dit toch lastiger volgens mij. Dus in die zin zit er wel *iets* in denk ik?

Kortom, ik denk dat het gebruiken van een minimale kernel wel wat zou kunnen uitmaken. Maar of je 20 dingen als module hebt geladen of diezelfde 20 dingen rechtstreeks in de kernel-image hebt gecompileerd, maakt dus niet heel veel uit - en het eerste is meestal een stuk handiger.

[ Voor 8% gewijzigd door Wilke op 13-10-2005 10:13 ]

[kenneth]

Onder FreeBSD kan je het securelevel omhoog gooien, waarna veel manieren om het systeem te compromitteren niet meer toegankelijk zijn: modules laden, naar /dev/kmem schrijven enzovoort.
Biedt Linux ook zoiets? Dat sluit volgens mij al heel wat potentiele exploits uit.

[igmar]

Een kleine kernel betekend niet meer kans op fouten. De meeste grote bugs waren de afgelopen tijd te vinden in het MM gedeelte en de netwerkstack. Geen systeem tegenwoordig die zonder kan.

Een niet-modulaire kernel is ook niet (veel) sneller : Op de tegenwoordige systemen merk je echt het kleine beetje overhead van de loader niet, en als het eenmaal geladen is is de snelheid gelijk. Ik bak zelf alles wat nodig is om te kunnen booten in de kernel, maar da's vooral omdat ik de neiging heb m'n ramdisk te verkloten

Beveiliging doe je door het systeem zowel intern als extern dicht te zetten, met om te beginnen een goed packetfilter die alles filtert, zowel uit als ingaand, wat niet nodig is. Zo verkom je dat er shells gebind worden en hackers op het systeem kunnen komen, of dat hackers externe tools ergens vandaan halen.

Het systeem zelf is minstens zo belangrijk : Timmer alles dicht wat niet nodig is. Compilers zijn voorbehouden aan bepaalde groepen, socketverbindingen idem. Verder is een patch als SELinux of grsec aan te bevelen, aangezien die je de mogelijkheid geven om je security aanzienlijk gedailleerd dicht te zetten. suid binaries zet je dicht voor gebruikers die 'm niet nodig hebben. Waarom het risico lopen dat problemen krijgt doordat gebruikers bv su of sudo misbruiken, als bij voorbaat al vaststaat dat die gebruikers uberhaupt geen su of sudo mogen gebruiken ?

Veiligheid door een kleine kernel of het uitzetten van modules is een illusie.

[Verwijderd]

igmar schreef op donderdag 13 oktober 2005 @ 10:28:
Een kleine kernel betekend niet meer kans op fouten. De meeste grote bugs waren de afgelopen tijd te vinden in het MM gedeelte en de netwerkstack. Geen systeem tegenwoordig die zonder kan.

Nu hebben we het alleen over Linux? Desondanks zijn er ook grote bugs die daar níét in zaten.

Een niet-modulaire kernel is ook niet (veel) sneller : Op de tegenwoordige systemen merk je echt het kleine beetje overhead van de loader niet, en als het eenmaal geladen is is de snelheid gelijk. Ik bak zelf alles wat nodig is om te kunnen booten in de kernel, maar da's vooral omdat ik de neiging heb m'n ramdisk te verkloten

Er is een verschil tussen een niet-modulaire kernel en een micro-kernel. Linux ondersteunt weliswaar modules, maar deze zitten nog steeds in de kernel-space. Als jij een module schrijft, dan kun je alles verprutsen in de kernel. Bij een microkernel kan dit niet. Dan krijg je wel veel context-switches, wat micro-kernels wel degelijk een performancenadeel geeft.

Beveiliging doe je door het systeem zowel intern als extern dicht te zetten, [...]

Het systeem zelf is minstens zo belangrijk : Timmer alles dicht wat niet nodig is. [...]
Waarom het risico lopen dat problemen krijgt doordat gebruikers bv su of sudo misbruiken, als bij voorbaat al vaststaat dat die gebruikers uberhaupt geen su of sudo mogen gebruiken ?

Waarom dan wel je kernel nodeloos uitrusten met filesystemen, soms zelfs web-servers, et cetera? Als je wilt voorkomen dat gebruikers processen in kernel-space misbruiken, waarom zou je ze die dan überhaupt laten gebruiken als het niet nodig is?

Veiligheid door een kleine kernel of het uitzetten van modules is een illusie.

[/quote]

Veiligheid is zo altijd een illusie. Je kunt altijd wel zeggen, 'Ja, maar, dan bestaat altijd die en die mogelijkheid nog'. Al deze beveiligingen maken het wel lastiger. Als een microkernel en een monolithische kernel even veilig zouden zijn wat kernel-exploits betreft, dan zou dat dus betekenen dat het aantal fouten gelijk is, en dat hoe meer code je toevoegt aan je monolithische kernel, hoe lager het aantal fouten/regels wordt? Dat lijkt me bizar. En dan hebben we het nog nieteens over alle wederzijdse afhankelijkheden van stukken code in een monolithische kernel, die waarschijnlijk ook niet afnemen als een kernel groeit.