Noch mehr Linux-Kernel-Sourcen-Security

Vor ein paar Tagen hatte ich mal die Frage aufgeworfen, warum die Linux-Kernel-Sourcen eigentlich mit den Zugriffsrechten World-Writable verteilt werden. Mir war daraufhin vorgeworfen worden, daß ich von Security keine Ahnung hätte, weil ich mich an allgemein schreibbaren Dateien störte. Obwohl ich dazu gar nichts mehr schreibe, geht der Spuk weiter, ich bekomme direkt oder als Cc: ständig weitere Mails mit absurden Standpunkten:

• Generell wird von (einigen) Kernel-Maintainern (oder solchen, die sich dafür halten) aggressiv die Meinung vertreten, daß man Kernel nicht als root, sondern mit einem normalen Account kompiliert. Auf meinen Hinweis, daß ein normaler Account viel zu gefährdet sei (z. B. Schwächen im Browser wie die hier) und die Gefahr einer Kompromittierung des Kernels zu groß sei, hieß es, daß man dazu selbstverständlich einen eigenen Account anlegt. Nur zum Kernel-Kompilieren.Normalerweise gilt es als Sicherheitsfehler, wenn unbenutzte Accounts herumstehen. Es steckt aber noch ein logischer Fehler dahinter: Jemand, der regelmäßig am Kernel herumschreibt, ihn ändert, ein- und auscheckt, Patches holt, Patches anwendet, herumexperimentiert, und ihn nicht einmal sondern hundertmal kompiliert, wird naheliegenderweise diese Arbeiten in seiner normalen Arbeitsumgebung und mit Internet-Zugriff ausführen. Da ist das naheliegend. Von der typischen Arbeitsweise eines Kernel-Developers aber auf den normalen Benutzer zu schließen und generell zu unterstellen bzw. zu fordern, daß der sich genauso verhält, ist Unfug.
• Ich habe die Klappe zu halten und den und diesen Thread zu lesen.

  Der erste Thread zeigt, daß auch andere diese Befürchtung hatte und ebenfalls blöde Antworten bekamen. So hieß es, die Rechte sind so eingestellt, daß der Compiler das kompilieren kann. Wem es nicht gefällt, der möge chmod verwenden.  Jetzt haben wir’s: Der eigentliche Grund ist, daß die Kernel-Maintainer zwar als normaler Benutzer in den Dateien herumeditieren und -kompilieren, die Dateien aber trotzdem Root gehören. Damit der Maintainer aus seinem normalen Account bequem kompilieren kann, muß es world writable sein. Grausig.

• Ein vernünftiger Grund wird nirgends genannt. Immer nur werden Leute als sicherheits-unfähig hingestellt, die Linux als root kompilieren, weil man doch einem fremden Tar-Archiv aus dem Internet nicht trauen könnte.

  Also ich soll dem tarball so sehr mißtrauen, daß ich ihn nicht mal auspacken darf, aber was da drin ist, soll ich hinterher bedenkenlos als  Kernel verwenden???

• Eine weitere Bemerkung, die den obigen Grund aufnimmt, scheint die eigentliche Ursache darzulegen:

  Es scheint so zu sein, daß die Maintainer, die hier so schrecklich “Security” brüllen, in Wirklichkeit aus Bequemlichkeit die Quellen bei sich selbst world writable haben, um sie von ihren Accounts aus zu ändern und zu kompilieren, und das Zeug dann einfach so einchecken. Ich kenne git nicht, aber das scheint der eigentliche Grund zu sein. Bequemlichkeit.
  

• Auch auf der Kernel-Maintainer-List (im oben angegebenen Thread) wieder die – unsinnige – Empfehlung, die umask auf 022 zu setzen. tar ändert die umask wieder. Bringt also gar nichts. Außerdem steht die umask sowieso normalerweise so.
• Git, das Versionsverwaltungsstool für Linux, hat das mal besser gemacht. Zitat:
  

  When git was introduced, permissions in generated tarballs were 644 and 755.
  People with umask 002 were upset.

  Aha. Irgendwer hatte sich also beschwert, daß die Dateien nicht Gruppen-schreibbar sind. Warum aber setzt man dann 666 und 777 statt 664 und 775 ? Das würde es doch tun!

• Ich bin nicht der einzige, der sich daran stört, daß ständig vom Thema abgelenkt wird: Mehrere haben gerügt, daß die Permissions im tar falsch sind. Immer wieder nur dieselbe Antwort: Man soll nicht als root kompilieren.
• Am Schluß wird die Schuld auf Gnutar geschoben, das die Rechte so setzt, wenn man unter root kompiliert.

  Bizarr: Einerseits heißt es, das die Rechte genau so sein müßten, damit die Maintainer bequem kompilieren können, andererseits soll es ein Bug von tar sein, daß es genau das tut, was angeblich so notwendig ist.

  Nur zur Erinnerung: tar ist ein Tape ARchiver, dessen Aufgabe es ist, Dateien genau so wieder reinzuspielen, wie man sie auf das Band rausgeschrieben hat. tar ist ursprünglich nur für root gedacht, und es ist kein Bug, daß tar das setzt, was im Archiv steht. Es wäre ein Bug, wenn es das anders machte. Es scheint überhaupt niemand nachzudenken und insbesondere hat da jeder eine andere Begründung und Sichtweise für das, was angeblich so offensichtlich ist.

Es gab inzwischen aber auch ein paar sinnvolle und zustimmende Hinweise:

• Seit git 1.4.2 (das Versionsverwaltungstool von Linux) ist es möglich, explizit eine umask für das zu erstellende tar anzugeben. Man hat nur vergessen es zu benutzen. Wenn es implementiert wurde, kann es aber nicht so unsinnig sein, wie mir (fast) alle vorwerfen.
• Kommentar zu dem Argument, ein Rechner mit Internet-Anschluß dürfe von vornherein keinen Compiler installiert haben:
  

  This sounds a lot like the school of security, not naming any names, where if there is a workaround it isn’t broken. […] Unless there is a good reason for these permissions, they are incorrect. It doesn’t make any difference if there are workarounds.

Schaue ich mir diese Diskussion an und die Art und Weise, wie diese file permissions  zustandekamen, wie sie mit völlig unsinnigen Argumenten und ohne triftigen Grund verteidigt werden, wie jeder, der Bedenken äußert in der Sache ignoriert und als Person angegriffen wird, kommen mir doch erhebliche Bedenken bezüglich der Sicherheit von Linux. Leuten, die so arbeiten, kann man vielleicht doch nicht die Sicherheit seines Rechners und seiner Daten anvertrauen.