linux kernel Vulnerability 2.6.X

Citaat:

---

Oorspronkelijk geplaatst door wv-

Je kijkt gewoon wanneer een vendor nieuwe patches/kernel uit brengt.

---

Maar dat betekent toch dat je elke ochtend even moet kijken of er nieuwe security-gerelateerde kernel patches zijn? Vervolgens moet je je eigen kernel patchen en upgraden. Het kan dan nog zijn dat je een probleem hebt, omdat er voor jouw eigen custom kerneltje geen kant-en-klare patch is en je dus zelf moet gaan hobbyen.

Citaat:

---

Oorspronkelijk geplaatst door wv-

Er zijn zelfs vendors die pas om de 6 maanden een nieuwe kernel uit brengen, dan wil je al sneller een eigen kernel.

---

Ik had het strikt over security-gerelateerde patches. En een nieuwe kernel om de 6 maanden van een vendor vind ik eigenlijk best snel. Ik draai hier een project (intern, niet aan een netwerk aangesloten) dat met een 2.4 kernel werkt. Waarom? Zo is het project een jaar of 3 geleden begonnen en die 2.4 werkt prima.

Jij moet toch ook elke morgend kijken of er geen security updates zijn voor jouw Vendor-kernel. Dat is toch juist het zelfde :).

Zolang de hardware werkt op 2.4, zonder veel geknoei ben ik zeker een voorstander van 2.4. Het spijtige is dat je vaak 2.6 nodig hebt en als je elke security bug fixed wilt zien je bijna elke week een kernel upgrade kan doen.

Citaat:

---

Oorspronkelijk geplaatst door bvankuik

Maar dat betekent toch dat je elke ochtend even moet kijken of er nieuwe security-gerelateerde kernel patches zijn? Vervolgens moet je je eigen kernel patchen en upgraden. Het kan dan nog zijn dat je een probleem hebt, omdat er voor jouw eigen custom kerneltje geen kant-en-klare patch is en je dus zelf moet gaan hobbyen.



Ik had het strikt over security-gerelateerde patches. En een nieuwe kernel om de 6 maanden van een vendor vind ik eigenlijk best snel. Ik draai hier een project (intern, niet aan een netwerk aangesloten) dat met een 2.4 kernel werkt. Waarom? Zo is het project een jaar of 3 geleden begonnen en die 2.4 werkt prima.

---

patches staan gewoon op www.kernel.org

jou kant en klare kernel kan nog weken wachten op een update,

een eigen gemaakte kernel kan je optimaliseren voor jou systeem , ik gebruik altijd eigen gecompilde kernels.

Citaat:

---

Oorspronkelijk geplaatst door wv-

Jij moet toch ook elke morgend kijken of er geen security updates zijn voor jouw Vendor-kernel. Dat is toch juist het zelfde :).

---

Dan kom je eigenlijk op mijn punt: Bugtraq kun je redelijk filteren, maar ik vind het toch veel tijd kosten om dagelijks +20 mailtjes door te snorren en te bepalen of het van toepassing is. Dat doet een vendor volgens mij beter.

Citaat:

---

Oorspronkelijk geplaatst door sander

jou (sp) kant en klare kernel kan nog weken wachten op een update

---

Ik had het over security updates. Als je daar weken op moet wachten, dan moet je een andere distro nemen....

Citaat:

---

Oorspronkelijk geplaatst door sander

een eigen gemaakte kernel kan je optimaliseren voor jou systeem , ik gebruik altijd eigen gecompilde kernels.

---

Ik vind vanilla 2.6 kernels van kernel.org de laatste tijd niet bijster robuust. Het voordeel van een stock kernel is dat de vendor een stabiele kernel versie selecteert, issues backport, zorgt dat de initscripts hier goed op aansluiten etc.

Als je dat niet wilt kan je evengoed de mails volgen van jouw vendor. Gebruik je een linux distributie, dan gebruik je allemaal dezelfde linux kernel :)

Citaat:

---

Oorspronkelijk geplaatst door bvankuik

Ik vind vanilla 2.6 kernels van kernel.org de laatste tijd niet bijster robuust. Het voordeel van een stock kernel is dat de vendor een stabiele kernel versie selecteert, issues backport, zorgt dat de initscripts hier goed op aansluiten etc.

---

Met 2.6 zit je inderdaad wel met dat probleem. Daarom dat er ook wel meer mensen overstappen naar bijvoorbeeld FreeBSD. Bij linux heb je altijd zo van die wazige kernel vulns waar geen degelijke advisories voor geschreven worden.

Het argument dat je aanhaalt kan je natuurlijk omdraaien: omdat ze zelf een kernel moeten onderhouden waarvan de fixes gebackport zijn, is er juist meer kans op onstabiliteit of op fixes waar je weken op moet wachten.

Citaat:

---

Oorspronkelijk geplaatst door wv-

Als je dat niet wilt kan je evengoed de mails volgen van jouw vendor. Gebruik je een linux distributie, dan gebruik je allemaal dezelfde linux kernel :)

---

Precies mijn punt. Lekker makkelijk; het mailvolume is veel en veel lager. Liever dat dan custom kernel plus elke ochtend minimaal 15 minuten bugtraq.

Citaat:

---

Oorspronkelijk geplaatst door wv-

Het argument dat je aanhaalt kan je natuurlijk omdraaien: omdat ze zelf een kernel moeten onderhouden waarvan de fixes gebackport zijn, is er juist meer kans op onstabiliteit of op fixes waar je weken op moet wachten.

---

Hangt van de distro af... RedHat sponsort zoveel kernel developers, die vertrouw ik wel. Debian ook, lekker conservatief.

Het lijkt mij niks om een kernel op een productiebak handmatig te moeten patchen. En upgraden naar de laatste vanilla kernel lijkt me ook niks. Natuurlijk kan je het wel, maar je mist dan de testfase die de vendors doen.

Je moet:
a. kijken of er een patch is
b. nagaan of de patch voor jou van belang is
c. testen of de patch niets verziekt

Dat moet je met een eigen kernel, dat moet je met de kernel van een vendor.

En dat moet je op ieder platform.. En zeer zeker ook op windows (mocht je dat draaien). Zelfs na een test blijkt de praktijk soms iets weerbarstiger.. zou niet de eerste keer zijn dat van 20 identieke winddozen er 1 plat gaat na een update.

Geef mij maar een custom made kernel.. geen onnodige ballast..

custom made kernels zijn erg moeilijk te beheren vooral je heel veel servers hebt. Wij gebruiken gewoon de stock RHEL kernels, weten we zeker dat het goed is. En al die balast dat is ook maar een broodje aap verhaal. Alles is zo'n beetje tegenwoordig in modules te krijgen... next!

Waarbij modules op zichzelf weer een security risk zijn ;-)

Custom made kernels hoeven niet moeilijk te beheren te zijn wanneer je veel dezelfde hardware hebt, en soms moet je wel.

Hij werkt niet op mijn redhat machine.. ben ik zo goed dan? :rolleyes:

De meest resente Redhat/Centos 4.3 Kernel die gereleased is: 2.6.9-34.0.2 (09-07-2006)

Wij draaien zelf 2.6.9-175 en 2.6.9-150

Citaat:

---

Oorspronkelijk geplaatst door WH-Tim

Hij werkt niet op mijn redhat machine.. ben ik zo goed dan? :rolleyes:

---

Nee, dat is SELinux ;-)