# Gentoo Security

## ro

Hi,

Also einer der Hauptgründe für Gentoo war für mich, dass Security-Patches relativ schnell zur Verfügung standen im Vergleich zu anderen Distris. Das hab ich immer geglaubt, bei http://www.pro-linux.de/news/2006/10058.html schneidet gentoo allerdings sehr schlecht ab. Glaubt ihr ist gentoo wirklich so langsam im Vergleich zu anderen? Ich dachte nie dass Debian schneller wäre ...

----------

## dakjo

 *Quote:*   

> ....Die Seite beschränkte sich allerdings bei ihrer Untersuchung nur auf die Geschwindigkeit, mit der Sicherheitslücken geschlossen wurden, und ließ die Qualität außer acht......

  *Quote:*   

> ....Denn Patches dürfen ein System nach einem Update nicht gefährden oder gar korrumpieren......

 

Und da Gentoo eine freie Distri ist, und nicht schon große komerzielle Unternehmen dahinterstehen finde ich, das sich Gentoo richtig gut macht.

Du mußt bedenken, das hier zu 99% alle in ihrer freizeit daran arbyten.

----------

## think4urs11

 *dakjo wrote:*   

>  *Quote:*   ....Die Seite beschränkte sich allerdings bei ihrer Untersuchung nur auf die Geschwindigkeit, mit der Sicherheitslücken geschlossen wurden, und ließ die Qualität außer acht......  *Quote:*   ....Denn Patches dürfen ein System nach einem Update nicht gefährden oder gar korrumpieren...... 
> 
> Und da Gentoo eine freie Distri ist, und nicht schon große komerzielle Unternehmen dahinterstehen finde ich, das sich Gentoo richtig gut macht.
> 
> Du mußt bedenken, das hier zu 99% alle in ihrer freizeit daran arbyten.

 

Das gilt für Debian allerdings auch und die hatten letztes Jahr da so ihre Problemchen da deren Security-'Team' faktisch nur noch aus einer Person bestand.

Inzwischen scheinen die es wieder im Griff zu haben, kann auch sein das sich da Ubuntu bemerkbar macht.

Ich kann nicht sagen wo es genau klemmt, evtl. zuwenige Member im Securityteam (die Securityissues überhaupt mitbekommen d.h. Mailinglisten wälzen; Patches suchen/melden (upstream)/erstellen), zu wenige Devs die dafür sorgen das die nötigen Ebuilds mit den Patches erstellt werden und dann in den stable-tree kommen (erst dann gibt es einen GLSA) oder ganz woanders.

...ganz blöde Möglichkeit: Alle security member sitzen innerhalb der gleichen Zeitzone - schon kann es mal einen Tag länger dauern im dümmsten Fall...

Generell gelten ja folgende Zeitfenster für security patches: http://www.gentoo.org/security/en/vulnerability-policy.xml#doc_chap3

Und im Vergleich zu Novell/SuSE (immerhin nicht die kleinste Firma mit bezahlten Entwicklern) stehen wir nicht ganz schlecht da; alles was oberhalb Gentoo in der Liste steht hat mindestens teilweise (direkten) Zugriff auf bezahlte Entwickler. (Debian z.B. rückwärts von Ubuntu, Fedora via RedHat)

----------

## dakjo

@Think4UrS11 genau.

Und da warte ich lieber auch nen Tag länger mit nem Sec-Fix als das danach mehr karput geht als das es nützt.

----------

## pablo_supertux

Außerdem denke, es hat im wesentlich auch damit zu tun, dass Gentoo eine Handvoll mehr Architekturen unterstützt als Ubuntu und das verzörgert ebenfalls die Bug Fixes

----------

## blu3bird

Ich glaub die haben bei der Statistik geschummelt  :Very Happy: 

Die beiden größten Distributionen nur auf Platz 3 und Platz 8? Obwohl die unmengen an Kohle da rein stecken?

Neeeee

Die haben aber für Gentoo schon die stable Version genommen oder wie? Oder nur die netten posts von GLSA? Denn wenn man die sich mal durchliest merkt mann, dass zumindest für meist schon seit längerem ne neuere version im portage ist die den Fehler behebt.

----------

## think4urs11

 *blu3bird wrote:*   

> Ich glaub die haben bei der Statistik geschummelt 
> 
> Die beiden größten Distributionen nur auf Platz 3 und Platz 8? Obwohl die unmengen an Kohle da rein stecken?
> 
> Neeeee

 

Wieso? Ist doch komplett logisch die Reihenfolge.

Ubuntu ist momentan _der_ Hype, hat nen sehr potenten Geldgeber im Rücken und hat Debian als Basis

RedHat ist ein sehr großer Laden mit vielen Kerneldevs u.ä.; Fedora _muß_ schneller sein als RHE weil es schließlich genau die Spielwiese für RHE ist

SuSE ist letztlich immer noch ein deutscher Laden, auch wenns Novell gehört und damit 120% gründlich und das dauert eben  :Wink: 

 *blu3bird wrote:*   

> Die haben aber für Gentoo schon die stable Version genommen oder wie? Oder nur die netten posts von GLSA? Denn wenn man die sich mal durchliest merkt mann, dass zumindest für meist schon seit längerem ne neuere version im portage ist die den Fehler behebt.

 

Soweit ich das verstanden habe gehen die nach security advisories und die gibt es bei Gentoo nunmal erst wenn ein betroffenes Paket für alle (betroffenen) arches stable ist; d.h. es kann gut sein das es ein (stable) mysql für x86 schon 1-2 Tage vor einem GLSA dafür gab weil noch auf sparc/ppc/amd64/... gewartet werden mußte.

----------

## ian!

Genau das ist das eigentliche Problem. - Die Pakete sind schon längst verfügbar, die GLSA aber nicht. Daher ist die erstellte Messung eigentlich nicht wirklich aussagekräftig. Bei Gentoo muss das GLSA halt auf (fast) jede Wald- und Wiesen Arch warten, dabei sind die Fixes für die populären Arches schon lange verfügbar und beim User auch schon meisst installiert.

----------

## dertobi123

 *ian! wrote:*   

> Bei Gentoo muss das GLSA halt auf (fast) jede Wald- und Wiesen Arch warten, dabei sind die Fixes für die populären Arches schon lange verfügbar und beim User auch schon meisst installiert.

 

Man sollte dann allerdings auch so fair sein und zugeben, dass es genauso gut Fälle gab und gibt, in denen "Wald- und Wiesen Architekturen" auf die "großen" wie x86 und amd64 warten ...

Das eigentliche Problem sind Pakete, die entweder ohne Maintainer im Tree liegen oder der Maintainer MIA ist. Bis dann irgendjemand bemüht wird das Problem zu lösen vergehen teils wertvolle Tage.

----------

## think4urs11

 *dertobi123 wrote:*   

>  *ian! wrote:*   Bei Gentoo muss das GLSA halt auf (fast) jede Wald- und Wiesen Arch warten, dabei sind die Fixes für die populären Arches schon lange verfügbar und beim User auch schon meisst installiert. 
> 
> Man sollte dann allerdings auch so fair sein und zugeben, dass es genauso gut Fälle gab und gibt, in denen "Wald- und Wiesen Architekturen" auf die "großen" wie x86 und amd64 warten ...
> 
> Das eigentliche Problem sind Pakete, die entweder ohne Maintainer im Tree liegen oder der Maintainer MIA ist. Bis dann irgendjemand bemüht wird das Problem zu lösen vergehen teils wertvolle Tage.

 

Klar, war ja auch nur ein Beispiel.

Vielleicht wäre es ja sinnvoll das GLSA-Procedere etwas anzupassen. So wie es jetzt ist ist es ja (genaugenommen) oft relativ kalter Kaffee; zumindest für die Leute die sich ihre tägliche Dosis emerge -uNDpv via script geben und/oder entsprechende Mailinglisten lesen.

Wäre ggf. besser den GLSA bereits dann rauszugeben sobald ein Patch für irgendeine der arches verfügbar ist, auch wenn er noch nicht stable ist und dann im weiteren Verlauf anzupassen wenn nacheinander die arches 'reintröpfeln' und stable werden.

Evtl. ja auch sowas wie ein GLSW d.h. kein advisory sondern ein warning ein machbarer Weg. Letztlich liegt es sowieso in der Verantwortung jedes Users/Admins wann/ob er Patches einspielt und die entsprechenden Tests dafür, Zeitfenster zu finden wann man darf etc. verschlingen ja auch nochmal Zeit.

Wobei (ich) wenigstens bei kritischen Securitybugs keine Zeitfenster mehr finden muß, das kann ich nach eigenem Ermessen, business-needs hin oder her; Security geht vor - paßt zwar vielen nicht aber am Ende hängt mein Job dran, sollen sie doch meckern. Zugegeben es war nicht leicht in diesen Status zu kommen aber den braucht man in so einer Position einfach. (sozusagen sowas wie die Doppel-Null-Lizenz für den IT-Bereich)   :Twisted Evil: 

Und das Argument 'wenn wir warnen ohne einen Patch zu haben spielen wir den bösen Buben in die Hände' lasse ich nicht gelten - die lesen die gleichen Mailinglisten wie die Security Bug Wrangler auch, wissen also Stunden/Tage vor (unbedarften) Usern/Admins von den Lücken.

----------

## slick

 *Think4UrS11 wrote:*   

> Und das Argument 'wenn wir warnen ohne einen Patch zu haben spielen wir den bösen Buben in die Hände' lasse ich nicht gelten - die lesen die gleichen Mailinglisten wie die Security Bug Wrangler auch, wissen also Stunden/Tage vor (unbedarften) Usern/Admins von den Lücken.

 

Naja, ich gehe einfach mal davon aus der sehr sicherheitsbewußte Anwender hält sich auch auf dem laufenden, nicht nur durch die GLSA. Und da es meist schon in ~x86 eine neuere Version gibt oder aber ein Patch existiert ist sollte man das nicht so heiß essen wie es gekocht wird. Würde man jetzt z.B. eine $ARCH-GLSA einführen wäre das Geschrei dann auch groß warum es für z.B. x86 schon raus ist aber nicht z.B. für PPC. Anderseits hätte das eine gewisse Motivation auf das langsamere ARCH-Team.

Was ich eher etwas kritischer sehe ist (anscheinend) werden Bugs zu ~x86 Paketen nicht als GLSA rausgegeben. Aufgefallen ist mir das ganze bei Firefox, als im Portage die 1.0.* stable war (Versionsnummern weiß ich nicht mehr genau) aber die 1.5.x nur als ~x86 verfügbar war. Da die neue Version ewig nicht stable wurde haben sehr viele die ~x86 installiert, wie man an den Forenposts ablesen konnte. Nun gab es aber in der ~x86 Version eine kritische Sicherheitslücke. Und genau vor der wurde nicht gewarnt. Klar, man könnte sagen die User sind selber schuld wenn sie ~ARCH benutzen, aber ich denke man kann das nicht so pauschalisieren, denn die Masse machts schließlich. Angenommen jetzt setzen 80% der User KDE 3.5.4 weil es so schön ist und da gibts eine kritische Lücke, dann sollte davor auch gewarnt werden da sonst 80% der User gefährdet wären. Aber das wird sicher personell seitens der Entwickler auch nicht möglich sein. Von daher denke ich kann man es eigentlich so lassen wie es ist, ansonsten müßte man es wirklich mal gründlich neu durchdenken bzw. neuorganisieren.

----------

## dertobi123

 *slick wrote:*   

> Was ich eher etwas kritischer sehe ist (anscheinend) werden Bugs zu ~x86 Paketen nicht als GLSA rausgegeben.

 

Die entscheidende Frage hier ist: Was kann ich mit den Mitteln die ich *derzeit* habe supporten? Und ~ARCH Pakete gehören da nunmal nicht zu, das ist nahezu ein Ding der Unmöglichkeit.

----------

## slick

Ist schon klar Tobi, ihr macht das schon gut! Ich wollte halt nur mal laut darüber nachdenken...  :Wink: Last edited by slick on Thu Aug 10, 2006 8:49 am; edited 1 time in total

----------

## Finswimmer

 *slick wrote:*   

> Ist schon klar Tobi, ich macht das schon gut! Ich wollte halt nur mal laut darüber nachdenken... 

 

Ich finde auch, dass die das sehr gut machen  :Wink: 

----------

## slick

AH!

buuuuuuuuummmmmmmmmmmmm.... *dumpfes Geräusch vom Aufschlagen des Kopfes auf der Tischplatte*

----------

## dertobi123

"Ich" im Sinne von "Gentoo" .... oder "ich" im Sinne von "XYZ"  :Wink: 

Interessant btw. dass es auf der sachlichen Ebene keine Einwände gibt, sondern so ein plumper Kram herhalten muss, um das Topic am Leben zu erhalten   :Cool: 

----------

## Finswimmer

 *dertobi123 wrote:*   

> "Ich" im Sinne von "Gentoo" .... oder "ich" im Sinne von "XYZ" 
> 
> Interessant btw. dass es auf der sachlichen Ebene keine Einwände gibt, sondern so ein plumper Kram herhalten muss, um das Topic am Leben zu erhalten  

 

Du hast es so gewollt  :Wink: 

Gibt es, abgesehen von Mailinglisten, eine Stelle, wo man für eine bestimmte Arch (z.B. x86) die aktuellen Lücken sehen kann?

Denn dann könnte man, bevor der GLSA für alle Archs draußen ist, seine Arch schon versuchen sicher zu machen...

Tobi

----------

## think4urs11

 *Finswimmer wrote:*   

> Gibt es, abgesehen von Mailinglisten, eine Stelle, wo man für eine bestimmte Arch (z.B. x86) die aktuellen Lücken sehen kann?
> 
> Denn dann könnte man, bevor der GLSA für alle Archs draußen ist, seine Arch schon versuchen sicher zu machen...

 

Deswegen ja weiter oben meine Anregung den GLSA-Prozeß evtl. in zwei Teile zu splitten.

a) wenn etwas hochkommt -> GLSW (warning) ins N&A-Forum 'so und so isses, das und das ist betroffen, Workaround (wenn möglich) soundso bis Patch verfügbar'

Diese Infos stehen i.d.R. ja bereits in der Mail/Website/whatever die auf den Bug aufmerksam machte, kann daher fast 1:1 kopiert werden. (Anpassung an ein bestimmtes Layout etc.)

b) wie gehabt GLSA (advisory), aber evtl. bereits ab dem Zeitpunkt 'erste arch stable' und dann weitere arches einfach als Post in den Thread anhängen 'arch PPC stable' statt wie bisher 'alles stable? -> GLSA raus'

Ob das arch-team nun in den Bug posted 'arch stable' und/oder in den Thread sollte nicht der showstopper sein/werden.

Hätte den Vorteil das die User sehr schnell informiert wären ohne das Hintergrundrauschen auf der Security-Mailingliste mitzubekommen.

Hätte weiterhin den Vorteil das einzelne Arches nicht auf die anderen warten müßten sondern ab dem Zeitpunkt 'stable for me' loslegen können mit der Patcherei.

Ich denke der zusätzliche Aufwand der dadurch entsteht wäre minimal und damit vertretbar.

dertobi123 hat da sicher viel besseren Einblick als unsereins vom gemeinen Fußvolk.

Und sofern einem vom Securityteam ein Bug für ein ~arch unterkommt (von dem zudem bekannt ist das es innerhalb der Usergemeinde sehr verbreitet ist; ggf. könnte man diese Info ja bald in gentoo-stats abgreifen) könnte daraus (denke ich) auch relativ schnell ein Warning generiert werden; meist beschränkt sich das Ganze ja (s.o.) auf Copy&Paste der Information. Wobei das natürlich nur das Sahnehäubchen wäre, man darf ja mal träumen  :Wink: 

----------

## dertobi123

 *Finswimmer wrote:*   

> Gibt es, abgesehen von Mailinglisten, eine Stelle, wo man für eine bestimmte Arch (z.B. x86) die aktuellen Lücken sehen kann?
> 
> Denn dann könnte man, bevor der GLSA für alle Archs draußen ist, seine Arch schon versuchen sicher zu machen...

 

Du kannst dir die Emails schicken lassen, die aus dem Bugzilla an security@gentoo.org geschickt werden ... das lässt sich im Bugzilla unter "Prefs" -> "Email Preferences" -> "unten versteckt auf der Seite" einrichten. Gibt (wenn sämtliche Kommentare etc. als Mail verschickt werden) irgendwas zwischen 10 und 50-60 Emails am Tag - also eine durchaus überschaubare Menge, die man ja eh nur grob nach für sich interessanten Dingen überfliegen muss. Ein wie ich finde vertretbarer Aufwand  :Wink:  Weiterhin gibts die Möglichkeit die Email Preferences im Bugzie so anzupassen, dass nur bei neuen Bugs für "security@gentoo.org" eine Mail kommt - das gilt dann aber als Einstellung für das gesamte Bugzie.

----------

## schachti

So, wie ich diese "Studie" verstanden habe, lief es so, daß die Distri mit dem schnellsten Patch 100 Punkte, die zweitschnellste 90 Punkte usw. bekommen hat, und die langsamste dann 0 Punkte. Anschließend wurde der Mittelwert gebildet.

Ich halte so eine Auswertung für wissenschaftlich zumindest fragwürdig. Zum einen sagt der bloße Mittelwert nicht viel aus, wenn nicht zumindest die Standardabweichung angegeben wird. Zum anderen ist die Punkteverteilung fragwürdig - Beispiel:

Distri A: 1 Stunde --> 100 Punkte

Distri B: 1 Stunde 1 Minute --> 90 Punkte

Distri C: 2 Wochen --> 80 Punkte

Die Punkte vermitteln in diesem Beispiel ein völlig falsches Bild, das mit der Wirklichkeit nichts zu tun hat. Man sollte also besser für jede Stunde, die zwischen Bekanntwerden des Bugs und der Veröffentlichung des Patches durch die Distri vergeht, einen Minuspunkt vergeben. Anschließend berechnet man die durchschnittlichen Minuspunkte und die Standardabweichung, und die Distri mit den wenigsten Minuspunkten gewinnt. Sowas hielte ich für seriöser.

----------

## Carlo

 *Think4UrS11 wrote:*   

> Deswegen ja weiter oben meine Anregung den GLSA-Prozeß evtl. in zwei Teile zu splitten.
> 
> a) wenn etwas hochkommt -> GLSW (warning) ins N&A-Forum 'so und so isses, das und das ist betroffen, Workaround (wenn möglich) soundso bis Patch verfügbar'

 

Das machte allenfalls Sinn, wenn man es konsequent durchziehen könnte, was schon daran scheitert, daß es keinen Zugang zu geschlossenen Listen wie Vendor Sec gibt, wenn man die Probleme nicht bis Termin X vertraulich behandelt. Abgesehen davon ist dafür nicht genug Manpower vorhanden; Und wenn, gäbe es tausende sinnvollere Aufgaben.

 *Think4UrS11 wrote:*   

> b) wie gehabt GLSA (advisory), aber evtl. bereits ab dem Zeitpunkt 'erste arch stable' und dann weitere arches einfach als Post in den Thread anhängen 'arch PPC stable' statt wie bisher 'alles stable? -> GLSA raus'
> 
> Ob das arch-team nun in den Bug posted 'arch stable' und/oder in den Thread sollte nicht der showstopper sein/werden.

 

Die Benachrichtigung rauszugeben und die sicherheitstechnisch unterstützten Architekturen so peu a peu stabil zu markieren, ist schlicht impraktikabel und inakzeptabel.

 *schachti wrote:*   

> So, wie ich diese "Studie" verstanden habe [...

 

Und alle Fragen offen - oder so. Das Ding ist mindestens "erklärungsbedürftig".

Siehe auch die auf den entsprechenden MailingListen geführten Diskussionen (gentoo-dev, gentoo-security).

----------

