Linux module sourcecode in static kernel compileren

[Verwijderd]

Hello

Ik heb een Highpoint HPT370 Raid controller op mijn ABIT mb zitten. Om deze aan de praat te krijgen via "hardware" raid (*) heb ik een module nodig van highpoint. Verschillende modules worden geleverd voor verschillende kernels. Wanneer ik een NIEUWERE kernel wil installeren kan ik een nieuwe module compileren dankzij de source code die highpoint op hun site zet (**).

Om verschillende redenen (***) zou ik graag deze driver (source code bedoeld om zelf een module te compileren) IN de kernel compileren, zodat ik een static kernel bekom (die het laden van modules niet ondersteunt).

Mijn vraag: is het mogelijk om deze sourcecode van highpoint (bedoeld om een module mee te compileren) op de een of anderen manier statisch in de kernel compileren? en zoja, hoe kan ik dat doen?

Reeds ontzettend bedankt voor jullie hulp

-----------------------------------------------------------------------------

(*) ik weet wel dat het meeste toch softwarematig via drivers wordt gedaan, en dat het performantie verschil tussen de higpoint hardware drivers en linux software raid klein is

(**) http://www.highpoint-tech.com/hpt3xx-opensource-v13.tgz
"This package contains Linux driver source code for HighPoint products - HPT370/370A/372/372A ATA RAID controllers.
The source code is for kernel updating purposes - you can use this source code to build a driver, if you cannot find one in HighPoint Linux driver release package. "

(***) veiligheid: het onmogelijk maken van installeren van root kits als module
snelheid: static kernel is sneller, ik weet toch exact wat erin moet en wat niet
flexibiliteit: ik zou graag redhat 8.0 installeren, maar daarvoor levert highpoint nog geen aangepaste boot diskettes, en via de highpoint driver diskette lukt het ook niet. De kernel vervangen op de originele redhat installatiediskette is mogelijk, dus als ik een kernel zou hebben met build-in support voor mijn raid controller kan ik die gewoon over de standaard redhat kernel zetten op die installatiediskette

[Verwijderd]

Verwijderd schreef op 01 november 2002 @ 22:14:
Om verschillende redenen (***) zou ik graag deze driver (source code bedoeld om zelf een module te compileren) IN de kernel compileren, zodat ik een static kernel bekom (die het laden van modules niet ondersteunt).

veiligheid: het onmogelijk maken van installeren van root kits als module

Sprookje.

Echt waar, dit is een sprookje. In static kernels kun je ook code toevoegen om rootkits te installeren.

snelheid: static kernel is sneller, ik weet toch exact wat erin moet en wat niet

Ook een sprookje.

De tijd per module zit 'em erin dat ie de hardware moet initialiseren. Het loaden van die paar kB aan data extra met een overhead van 1% is niet merkbaar. anders zou je nl. deze data on bootup moeten loaden, en dat is dus slechts 1% verschil op die 1% die het laden van de data kost. Niet merkbaar.

flexibiliteit: ik zou graag redhat 8.0 installeren, maar daarvoor levert highpoint nog geen aangepaste boot diskettes, en via de highpoint driver diskette lukt het ook niet. De kernel vervangen op de originele redhat installatiediskette is mogelijk, dus als ik een kernel zou hebben met build-in support voor mijn raid controller kan ik die gewoon over de standaard redhat kernel zetten op die installatiediskette

Als ik 't goed heb is die kernel image ook initrd-based, toch? .

Mijn vraag: is het mogelijk om deze sourcecode van highpoint (bedoeld om een module mee te compileren) op de een of anderen manier statisch in de kernel compileren? en zoja, hoe kan ik dat doen?

Ja. Maar dan heb je een zekere mate van kennis van de kernel nodig, en dat vind ik nou eigenlijk de moeite niet waard...

Ik ben juist groot voorstander van "alles een module", waarbij in-kernel niet meer mogelijk is. Ook Alan Cox heeft dit idee al vaker dan eens aangeprezen, en ik heb begrepen dat dit in kernel 2.6 of 2.7 (2.8/3.0) "in de kernel" komt, dus dat in-kernel dan niet meer mogelijk is en alles een module wordt.

[Lancer]

Ik gebruikte vroeger ook static kernels, maar daar ben ik vanaf gestapt. Het systeem werkt beter met modules. Diverse stukken software verwachten een module en raken in de war als die er niet is. Kun je wel weer gaan truken, maar gewoon modules gebruiken is makkelijker.

[_JGC_]

Modules zijn gewoon buitengewoon handig. Zo heb ik bijvoorbeeld altijd ruzie met IPTables: wat willen we wel, wat willen we niet. Hoppa, alles als module, de kernel module autoloader pakt wel wat ie nodig heeft
Verder is het wel makkelijk voor netwerkkaarten. Stel je voor: je draait je hele netwerk op Realtek. Vervolgens krijg je van iemand een stel afgedankte 3COM kaarten en wil je die erin drukken. Ik zie mezelf nog niet voor elke machine een kernel compilen, ik gooi gewoon de realtek module eruit en pak de 3com module.

[DPLuS]

Door beelzebubu - 02-11-2002 10:10 quote

quote:
--------------------------------------------------------------------------------
backbone schreef op 01 november 2002 @ 22:14:
Om verschillende redenen (***) zou ik graag deze driver (source code bedoeld om zelf een module te compileren) IN de kernel compileren, zodat ik een static kernel bekom (die het laden van modules niet ondersteunt).

veiligheid: het onmogelijk maken van installeren van root kits als module

--------------------------------------------------------------------------------


Sprookje.

Echt waar, dit is een sprookje. In static kernels kun je ook code toevoegen om rootkits te installeren.

Ehr, dit was nou exact mijn argument om een monolithic kernel te bakken.
Hoe kan men dan code toevoegen in static kernels??

[Verwijderd]

Verwijderd schreef op 01 november 2002 @ 22:14:
Hello

Ik heb een Highpoint HPT370 Raid controller op mijn ABIT mb zitten. Om deze aan de praat te krijgen via "hardware" raid (*) heb ik een module nodig van highpoint.

Onzin. De drivers zitten vanaf 2.4.10 bij de kernel, dus waarom moeilijk doen met HighPoint drivers.

[Verwijderd]

Sprookje.

Echt waar, dit is een sprookje. In static kernels kun je ook code toevoegen om rootkits te installeren.

Is het dan mogelijk, zonder de /boot/vmlinuz kernel file te overschrijven en te rebooten, om een monolitic kernel (waarbij module support gedisabled is) aan te passen? Wat bedoel je daarmee? Deze tip om een monolitic kernel te bouwen om het laden van rootkits tegen te gaan komt uit magazine voor computertechniek: C'T

Onzin. De drivers zitten vanaf 2.4.10 bij de kernel, dus waarom moeilijk doen met HighPoint drivers.

Waarom levert highpoint aangepaste installatiediskettes, kernels en drivers voor redhat 7.3 (die met kernel 2.4.18 werkt btw)? En waarom lees ik her en der berichten op forums waarin andere gebruikers ook vaststellen dat hpt370 drivers in de kernel de controller ENKEL doen werken als ide controller, niet als raid controller? Op gelijk welke ide controller kan dan natuurlijk (nadat de ide controller herkend wordt door de kernel) linux software raid op toegepast worden. Werken met de drivers van highpoint heeft de volgende extra voordelen: de bios herkent de partities, en zowel onder linux als onder windows kan gebruik gemaakt worden van dezelfde array.

Als ik 't goed heb is die kernel image ook initrd-based, toch?

idd, maar 'k heb is geprobeerd die highpoint module in die initrd te steken op de installatiediskette, maar het lukt mij niet die module te laden tijdens de installatie procedure van redhat.

Voor het toevoegen van de hpt37x.o module heb ik een procedure gevolgd volgens dit bericht: http://www.redhat.com/mai...kstart-list/msg02188.html

Wat gebeurt er bij het booten van de aangepaste redhat 8.0 bootdiskette:
• Hij laadt mijn aangepaste kernel: ok.
• Hij laadt mijn aangepaste initrd: ok.
• Hij vraagt naar installatiemedium (hardeschijf of cdrom). Ik kies cdrom
• Een beetje later zegt hij dat hij geen hardeschijven gevonden heeft. Met ctrl+F3 kan ik log berichten zien, ik kan echter niet terugscrollen. Ook in een of ander log filetje dat ik in /var vond staat niks over mijn module. Hij zaagt wat over mod_scsi module die hij niet vindt, maar niks over mijn highpoint module. Met ctrl+F2 heb ik een shell, daarin zie ik dezelfde filenames in directory modules als diegene vanop mijn floppy, maar met ANDERE inhoudt, zonder mijn module erin. Blijkbaar is hij die toch vanaf de cd gaan halen.

Ik weet het echt niet meer...

[igmar]

Verwijderd schreef op 02 november 2002 @ 10:10:
Sprookje.

Echt waar, dit is een sprookje. In static kernels kun je ook code toevoegen om rootkits te installeren.

Alleen mogelijk indien je mag schrijven in /dev/[k]mem. Normaliter kun je dat als root, maar met grsecurity kun je dat ondervangen.

Op een hardened OS is het gebruik van modules zeer onwenselijk, en het runtime inserten van code in de kernel al helemaal. Voor normaal gebruik hebben modules inderdaad meer voordelen als nadelen, al zul je dingen zoals ext2 / ext3 in je kernel moeten bakken. initrd is gewoon vreselijk lelijk

[Buffy]

igmar schreef op 02 november 2002 @ 22:11:
[...]


Alleen mogelijk indien je mag schrijven in /dev/[k]mem. Normaliter kun je dat als root, maar met grsecurity kun je dat ondervangen.

Op een hardened OS is het gebruik van modules zeer onwenselijk, en het runtime inserten van code in de kernel al helemaal. Voor normaal gebruik hebben modules inderdaad meer voordelen als nadelen, al zul je dingen zoals ext2 / ext3 in je kernel moeten bakken. initrd is gewoon vreselijk lelijk

Je zou natuurlijk een systeem kunnen implementeren waarbij alleen gesignde modules geladen kunnen worden zodat alleen de door de "echte" root gecompileerde en gesignde modules toegestaan zijn.
Maar dan moet inderdaad wel de achteringang via /dev en /proc worden gedicht

[ Voor 0% gewijzigd door Buffy op 02-11-2002 22:39 . Reden: slechte zinsbouw ]

[Verwijderd]

Verwijderd schreef op 02 november 2002 @ 16:37:
Is het dan mogelijk, zonder de /boot/vmlinuz kernel file te overschrijven en te rebooten, om een monolitic kernel (waarbij module support gedisabled is) aan te passen? Wat bedoel je daarmee? Deze tip om een monolitic kernel te bouwen om het laden van rootkits tegen te gaan komt uit magazine voor computertechniek: C'T

Je kan gewoon at runtime, dus zonder schrijven of rebooten, execcode toevoegen. Hoe weet ik niet, dat moet je Alan Cox vragen.

[igmar]

Dawns_sister schreef op 02 november 2002 @ 22:37:
[...]

Je zou natuurlijk een systeem kunnen implementeren waarbij alleen gesignde modules geladen kunnen worden zodat alleen de door de "echte" root gecompileerde en gesignde modules toegestaan zijn.
Maar dan moet inderdaad wel de achteringang via /dev en /proc worden gedicht

Via /proc kan het al niet, /proc/kcore is read-only. /dev/[k]mem kun je wel schrijven als root, dus het leak zit 'm daar in. Merk wel op dat het inserten van runtime code wel expertise vereist, het is geen script-kiddie beproofte techniek.

Aan de gesignde modules/exe's is wel gedacht, maar vooral met exe's geeft dit veels te veel overhead.

[Verwijderd]

Maar wat is het probleem hier? Root kits dienen om root access te krijgen, dus wat hebben die hackers er dan aan dat /dev/[k]mem voor root beschrijfbaar is, als ze helemaal nog geen root access hebben?

Voor de rest: zijn er ergens goeie manuals/howto's te vinden over hoe modulesourcecode statisch bij een monolitic kernel kan gecompileerd worden?

thx already

[DiNo!]

Verwijderd schreef op 01 november 2002 @ 22:14:
Hello

[...]

Om verschillende redenen (***) zou ik graag deze driver (source code bedoeld om zelf een module te compileren) IN de kernel compileren, zodat ik een static kernel bekom (die het laden van modules niet ondersteunt).

[...]

Jij hebt zeker de linuxfocus van november gelezen??
Root-kits and integrity

[Verwijderd]

Verwijderd schreef op 04 november 2002 @ 20:11:
Maar wat is het probleem hier? Root kits dienen om root access te krijgen, dus wat hebben die hackers er dan aan dat /dev/[k]mem voor root beschrijfbaar is, als ze helemaal nog geen root access hebben?

Is een rootkit er niet voor om als je eenmaal root bent, root te blijven. En wel zo dat de 'echte' root er niet achterkomt....

[Verwijderd]

Verwijderd schreef op 04 november 2002 @ 20:11:
Maar wat is het probleem hier? Root kits dienen om root access te krijgen, dus wat hebben die hackers er dan aan dat /dev/[k]mem voor root beschrijfbaar is, als ze helemaal nog geen root access hebben?

Dus op jouw systeem mogen users zomaar kernel module's insmodden?

Vreemde vorm van security. .

[Verwijderd]

nee sorry mijn fout, ff verstrooid
root kits dienen idd om root kits te BEHOUDEN door o.a. hun acties onzichtbaar te maken en dergelijke

de vraag over --sourcecode die voor module compilatie is gemaakt, statisch in een monolitic kernel te compileren-- blijft echter...

[_JGC_]

Verwijderd schreef op 04 november 2002 @ 21:14:
[...]
Is een rootkit er niet voor om als je eenmaal root bent, root te blijven. En wel zo dat de 'echte' root er niet achterkomt....

Daar heb je echt geen rootkit voor nodig...
Klasgenoot laatst gedaan:
"Hey, kan je me ff helpen met mn linux server? mn root pass is ******"
"Jazeker, clicketieclicketie, httpd user met uid 0 in /etc/passwd"

hij is nu twee weken verder, elke keer als mn klasgenoot inlogt in die bak met z'n httpd user, vim't ie ff /var/log/syslog en die gozer ziet er niets van. Tja, niet iedereen is slim

Op school gaan we een systeem opzetten met een centrale "Big Brother" server, waarbij MD5 sums van belangrijke bestanden op de verschillende machines in de gaten worden gehouden. MD5 sum anders? Alert. rootkits hebben dan geen kans met hun std aangepaste ls en ps bestandjes

[Verwijderd]

_JGC_ schreef op 04 november 2002 @ 21:48:
[...]
MD5 sum anders? Alert. rootkits hebben dan geen kans met hun std aangepaste ls en ps bestandjes

Er zijn ook rootkits die door het inladen van een module de werking van de kernel wijzigen, zonder dat ze daarvoor fysiek bestandjes als ls en ps moeten aanpassen, en die toch de werking ervan beïnvloeden...

Om deze soort van rootkits tegen te gaan wil een monolitic kernel wel is helpen. Na het eventueel vervangen van de kernel naar een niet-monolitic kernel moet er namelijk worden gereboot. Daarna moet er eventueel via een bios opstartpassword worden opgestart (wat niet remote meer gaat, zelfs niet lokaal zonder kast open te vijzen), zodat er toch al IETS op wijst dat er gefoefeld is. Een clean kernel booten op een opstartdisketje en dan de boel checken is dan een mogelijkheid.

Er zullen altijd wel omzeilmethodes zijn, maar 't is toch een stap in de goede richting dacht ik, om een monolitic kernel te gebruiken.

En zoals reeds eerder vermeld, tips i.v.m. de hamvraag van deze topic (zie vette tekst eerste bericht) zijn altijd welkom

[Buffy]

_JGC_ : Maar met een kernel module kan je juist de open() calls (e.d.) afvangen en dan hoef je commando's als ls en ps helemaal niet te vervangen om onzichtbaar te worden.

[ Voor 0% gewijzigd door Buffy op 04-11-2002 22:26 . Reden: sneller typen :-) ]

[Verwijderd]

Verwijderd schreef op 04 november 2002 @ 21:40:
de vraag over --sourcecode die voor module compilatie is gemaakt, statisch in een monolitic kernel te compileren-- blijft echter...

Ik heb nou al een aantal keren uitgelegd waarom dat geen zin heeft. Sorry, maar dan heeft 't gewoon weinig zin om 't uit te leggen. Mag arrogant klinken, maar ik heb d'r geen zin in. 't Is zinloos. Non-modulaire kernels zijn net zo (on)veilig als modulaire kernels. initrd (ramdisk-booted-module-loading) is nou juist ontworpen om de laatste reden om geen modules te gebruiken weg te halen.

Face it, modules worden een onverwijderbare optie. Wen d'r maar vast aan.

[DiNo!]

Verwijderd schreef op 04 november 2002 @ 22:23:
[...]

Om deze soort van rootkits tegen te gaan wil een monolitic kernel wel is helpen. Na het eventueel vervangen van de kernel naar een niet-monolitic kernel moet er namelijk worden gereboot.

[...]

Er zullen altijd wel omzeilmethodes zijn, maar 't is toch een stap in de goede richting dacht ik, om een monolitic kernel te gebruiken.

[...]

Wat je zegt is natuurlijk waar maar lees deze quote eens uit de linuxfocus van deze maand

However, even if the kernel does not have module support, it is possible to load some of them into memory (not that simple). Silvio Cesare wrote the kinsmod program, which allows to attack the kernel via the /dev/kmem device, the one managing the memory it uses (read runtime-kernel-kmem-patching.txt on his page).

[igmar]

Verwijderd schreef op 04 november 2002 @ 23:13:

Ik heb nou al een aantal keren uitgelegd waarom dat geen zin heeft. Sorry, maar dan heeft 't gewoon weinig zin om 't uit te leggen. Mag arrogant klinken, maar ik heb d'r geen zin in. 't Is zinloos. Non-modulaire kernels zijn net zo (on)veilig als modulaire kernels. initrd (ramdisk-booted-module-loading) is nou juist ontworpen om de laatste reden om geen modules te gebruiken weg te halen.

Face it, modules worden een onverwijderbare optie. Wen d'r maar vast aan.

Misschien dat Alan Cox d'r zo over denkt, maar een aanzienlijk gedeelte van de users (waaronder ik) dus niet.

Initrd is lelijk, lastig te installeren, helemaal lastig om te maken, en verspilling van geheugen.

Een van de redenen waarom een kernel nooit module-only zal worden is embedded toepassingen, tenzij iemand aparte patches gaat bijhouden / een aparte fork van de source gaat opzetten.

Modulaire kernels zijn wel degelijk onveiliger als non-modulaire kernels, zolang iemand geen write access op /dev/[k]mem heeft is het ondoenlijk om runtime code te inserten. Bij een modulaire kernel is het gewoon insmod stealth_module en probeer er dan nog maar eens achter te komen dat je gehacked bent.

[igmar]

DiNo7 schreef op 05 november 2002 @ 08:39:
Wat je zegt is natuurlijk waar maar lees deze quote eens uit de linuxfocus van deze maand

Hetgeen je als beheerder meteen dichtzet dmv grsecurity

edit:
Met grsecurity kun je overigens ook het laden van modules controleren / zichtzetten