Wie Ubuntu Linux bei der IT Sicherheit pfuscht

Über technische Probleme, mangelnde Kompetenz und ideologische Sichtweisen.

Viele Leute sagen, daß Open Source Software ja viel sicherer als kommerzielle Software sei. Und daß Linux sicherer als Windows ist. Und so weiter. In manchererlei Hinsicht stimmt das ja auch. Und das war auch mal richtig. Aber es stimmt schon lange nicht mehr so, daß diese Aussage pauschal haltbar wäre.

Ich habe hier schon öfters geschrieben, daß mir immer wieder mal gewisse Beobachtungen im Linux-Umfeld, die auch mit Sicherheit zu tun haben, gewaltig gegen den Strich gehen, und man sich dann gegen so eine Ideologie-Wand fusselig reden kann, aber gegen deren Ignoranz mit Argumenten einfach nicht ankommt. Beispielsweise zu der bekloppten Frage, warum Linux-Kernel-Sourcen in den Tar-Files lange Zeit mit Rechten 666 (a=rw) verteilt wurden. Oder der Schwachsinn um den Network Manager, der keine pre-down-Phasen erlaubt, weil ein Netzwerk es ja auch aushalten müsse, wenn der Strom ausfällt. Oder dieses hirnrissigen und unkontrollierbaren Auswucherungen der Desktop-Software, die selbst Passworte, Netzwerkkonfigurationen und Rechtevergabe über einen undokumentierten D-Bus-Wirrwarr schicken wollen und dabei jedes Debugging, jede Überprüfung unmöglich machen. Oder daß man mit upstart den Bootprozess rapide beschleunigen will, dabei aber nicht daran gedacht hat und nicht gewährleisten kann, beispielsweise ein Firewallskript vor dem Hochfahren der Netzwerkinterfaces vollständig auszuführen.

Nun habe ich wieder so einen Fall.

Es wird ja auch in der Presse immer das Märchen kolportiert (und von erstaunlich vielen Leuten in meinem Bekanntenkreis geglaubt), daß jüngere Leute so viel besser mit dem Computer-Kram umgehen könnten als die Älteren. Da kommen dann solche Dummsprüche wie daß die sogenannten „Digital Natives”, also die, die mit dem Internet-Zeugs aufgewachsen sind, den Älteren, die als „Digital Immigrants” gelten, die ohne Internet aufgewachsen sind und das alles erst nachträglich lernen mußten, haushoch überlegen seien. So als ginge es um eine Muttersprache gegenüber einer nachträglich erlernten Sprache. (Nur sehr selten wird noch eine dritte Kategorie erwähnt, nämlich die derjeniger Älteren, die den ganz Kram entwickelt und aufgebaut hat, und im Gegensatz zu den Jüngeren auch noch weiß, wie das alles entstanden ist, warum es so ist wie es ist und was unter der Haube abläuft.)
Gerade so als ob eine Generation von Jüngeren, die schon selbst nicht mehr weiß, wie sie auch nur einen Schultag ohne Handy, ohne Twitter und ohne Facebook überstehen soll, und die völlig unkritisch ist, per se besser mit dem Computer umgehen könnte, als der, der noch weiß, was drinnen steckt.

Oder salopp gesagt: Ich beobachte immer wieder, daß die „Generation C-64” der „Generation Windows” fachlich-inhaltlich haushoch überlegen ist, auch wenn man nicht jedes Desktop- und Social-Network-Feature drauf hat. Alles geht in die Breite, nichts mehr geht in die Tiefe.

Ein anderes Problem ist ein Zeitgeistproblem, eine soziologisch-kulturelle Krankheit, wie sie auch Wikipedia befallen hat. Die Leute sind nicht mehr für Argumente empfänglich. Die prüfen nichts mehr nach. Es gibt so diese „meine-Ideologie-ist-maßgeblich-und-alles-andere-wird-gelöscht”-Mentalität. Es hat sich so eine Kultur der Beliebigkeit ausgeprägt, die Sichtweisen über fachliche Argumente stellt. (Was sicherlich auch mit der Medienlandschaft, der Werbung, der immer mehr ansteigenden Beeinflussung und dem Verlust der Wissenschaftlichkeit einhergeht.) Nicht das Aufwachsen mit dem Internet ist prägend, sondern das Aufwachsen in einer Kultur der Willkürlichkeit. Mit vielen dieser Leute ist nichts mehr anzufangen.

Und man merkt diesen Generationenwechsel sehr, sehr deutlich. An Linux zum Beispiel. Früher war das mal robust, stabil, kompakt. Inzwischen wird es immer schlechter. Die Featuritis, die Klickeritis und die Twitteritis greifen um sich. Ob man beim Desktop noch durchblickt und das stabil läuft, interessiert keine Sau mehr. Hauptsache das Ding hat in der Menüleiste out of the Box Buttons für alle Chat- und Twitter- und Social- Netwerke.

Als Folge dessen gibt es gerade keinen Web-Browser, dem ich richtig vertrauen würde. Andauernd gibt es irgendwelche Sicherheitslücken, Pufferüberläufe, Um-die-Ecke-URLs und was weiß ich nicht alles. Und dann noch diese unsägliche Flash- und PDF-Fehler. Guckt Euch nur mal diese endlose Liste von Sicherheitslücken allein im neuesten Security-Bulletin von Adobe zu Flash an. Da wird doch der Hund in der Pfanne verückt. Und ohne geht’s dann auch nicht, weil immer mehr Deppen irgendwelche Webseiten in Flash programmieren müssen. Weil halt auch immer mehr Leute unterwegs sind, die das und nichts anderes gelernt haben.

Was macht also der Mann von Welt? Wenn man noch auf die Mehrzahl der Webseiten zugreifen will ohne sich allzusehr zu gefährden?

Man greift zu Sicherheitsmaßnahmen. AppArmor wäre das Mittel der Wahl. Hinreichend pragmatisch und bedienbar, nachdem sich SELinux als hyperkomplexe und unbedienbare Totgeburt herausgestellt hat. Da würde man mit AppArmor einfach die Zugriffsrechte von Firefox drastisch einschränken und schon wäre es ein deutlich geringerer Schaden, falls mal irgendwer das Ding aufbohrt. Könnte nicht gleich alles auskundschaften oder Malware auf die Platte schreiben. Nur wird das Ding unter Ubuntu auch nicht sauber gepflegt. Die meisten Applikationen haben kein AppArmor-Profile. Es gibt zwar eine Sammlung, aber die muß man erst aktivieren und ungepflegt ist sie auch.

Neuerdings haben sie bei Ubuntu dann doch mal ein AppArmor-Profile beim Firefox mit richtigem Pfad beigefügt. Wäre ja mal ein Ansatz. Guckt man dann aber mal in /etc/apparmor.d/usr.bin.firefox rein, haut’s einen vom Stuhl. Da steht dann u.a. sowas drin:

 # allow access to documentation and other files the user may want to look
  # at in /usr
  /usr/ r,
  /usr/** r,

  # so browsing directories works
  / r,
  /**/ r,

  # allow read and write to all user's files, except explicitly denied ones
  @{HOME}/ r,
  @{HOME}/** r,
  owner @{HOME}/** w,
  owner @{HOME}/Desktop/** r,

  # removable media and filesystems
  /media/** r,
  /mnt/** r,
  /srv/** r,
  owner /media/** w,
  owner /mnt/** w,
  owner /srv/** w,

Also wird Schreib- und Lesezugriff auf praktisch alles gewährt, was der Benutzer mit seinen Unix-Rechten sowieso schreiben und lesen darf. Nicht ganz. Es gibt darin auch

  #include <abstractions/private-files>

wo ein paar einzelne Ausnahmen definiert sind (und in einem Datenformat, das es laut der zugehörigen Man-Seite gar nicht geben dürfte). Das heißt, daß man dort eine Negativ-Liste aufbauen muß.

Das ist nicht gut. Fehleranfällig, Pflegebedürftig, Sicherheitslöchrig.

Dabei ginge es viel besser. Das apparmor-Paket selbst bringt eine Datei /etc/apparmor.d/abstractions/user-download (aber seltsamerweise kein user-upload) mit, in der definiert ist, wo Downloads hingehen könnten:

 
  @{HOME}/tmp/**                rwl,
  @{HOME}/download/**           rwl,
  @{HOME}/downloads/**          rwl,
  @{HOME}/[a-zA-Z0-9]*          rwl,
  @{HOME}/Desktop               r,
  @{HOME}/Desktop/*             rwl,
  "@{HOME}/My Downloads/"       r,
  "@{HOME}/My Downloads/**"     rwl,

Na also, es ginge doch wenn man wollte.

Würde man auch eine zweite Datei für user-uploads anlegen, dann könnte man hübsch über eine Positive-Liste festlegen, wo Dateien rauf- und runtergeladen werden dürfen. Und das hätte noch den Vorteil, daß es aus der eigentlichen /etc/apparmor.d/usr.bin.firefox ausgelagert wäre. Denn wenn man die ändert, kann man in Probleme kommen. Debian/Ubuntu überprüft nämlich, ob der Admin Dateien in /etc geändert hat. Falls ja, werden sie nicht unbedingt überschrieben. Das heißt, wenn der Admin an der Datei für Firefox was ändert, dann behält er bei einem Paket-Upgrade entweder seine alte Datei und bekommt dann Updates des Maintainers nicht mit, wenn also Firefox mal auf was neues zugreifen muß oder wenn sich der Pfad des Binaries ändert, was zum völligen Sicherheitsverlust führen kann, weil dann das AppArmor-Profile nicht mehr angewandt wird, oder er übernimmt das neue Profile und läuft gefahr, doch die Hütte wieder offen zu haben, wenn er nicht sofort wieder seine Änderungen einpflegt. Dabei könnte es eben über diese Abstractions so einfach und zuverlässig sein.

Also habe ich einen Bug-Report aufgemacht (böses ahnend, denn das hatte ich vor längerer Zeit schon mal angemeckert). Und als Beispiel auf aktuelle Flash- und PDF-Schwächen hingewiesen. Es kam, wie es kommen mußte. Der Bug-Report wurde sofort als „invalid” geschlossen. Die Begründung eines gewissen Jamie Strandboge:

Thank you for using Ubuntu and reporting a bug.

First off, in a standard Ubuntu install, PDFs are handled by evince, which is covered by an AppArmor profile and if the firefox profile is enabled it will run evince confined.

Second, if the firefox profile is enabled and is configured to use nspluginwrapper, when flash content is processed, firefox transitions to unconfined. Depending on the vulnerability, it may or may not be confined by the profile. If the user installs acroread and configures firefox to use it instead of evince, the same thing will happen if there
is a vulnerability in acroread. As an aside, this is generally not the case for addons and extensions since they execute within the firefox context rather than a separate exec.

Keep in mind a couple of things:

1. The goal of the firefox apparmor profile is not to protect the user from herself, but instead to add a layer of protection against *firefox* executing code and launching other attacks. Due to a number of factors, not least of which usability and development time, the firefox profile will run many helper applications unconfined.
2. Users expect to be able to download and upload files, as well as access those files on removable media. Also, these lines apply to directories only:
   / r,
   /**/ r,
3. The profile explicitly denies read/write access to sensitive files
   via the priate abstraction and write access to ~/bin (which is in the
   user’s PATH).

All of these things combined does improve the security stance of firefox, by effectively making it run within a sandbox. That said, it is recognized that security minded people and enterprise users will want to make the profile less general purpose and further restrict firefox, which is why the profile is shipped in /etc as a configuration file. It is planned that Ubuntu 10.10 will make it easier to fine browser profiles.

For more information on the design of the profile, please see https://wiki.ubuntu.com/SecurityTeam/Specifications/Karmic/AppArmorFirefoxProfile

Da geht mir der Deckel hoch.

Dieses saublöde Argument, daß die Benutzer es doch so wollen. Und überhaupt die Argumentation: Bei Code Execution läuft es dann auf unconfined hinaus, während bei Angriffen, die noch im Browser laufen, der Zugriff auf alle Dateien auch möglich ist. Hä!? Im einen Fall gibt es keinen Schutz, im anderen also auch nicht? Irgendwie hat der mich auch nicht verstanden. Daß die Mehrzahl der Benutzer damit überfordert wäre, wenn Firefox per Default nicht auf alle Dateien zugreifen könnte, ist mir klar. Mein Punkt war ja aber doch, daß die wenigen, die sich auskennen, es gerne straffer hätten, es einem Ubuntu durch den Nichtgebrauch von abstractions es einem zu schwer macht, von deren Vorgabe abzuweichen, es also dauerhaft und fehlerarm zu ändern. (Wie schon beschrieben, behält man bei einem der häufigen Packageupdates seine alte Konfigurationsdatei, kann es zu Funktionsstörungen oder zum gänzlichen Verlust der Schutzfunktion kommen. Übernimmt man die neue Datei ohne sie handzudengeln, steht man wieder offen wie ein Scheunentor.) Kapiert der gar nicht erst.

Der versteht überhaupt nicht, worauf ich hinauswill und gibt mir so eine Pauschalbelehrung. Invalid, abgehackt. Wie das Löschen in der deutschen Wikipedia.

Und ich hake nach. Erkläre die Fehler. Und erlaube mir die Frage, ob er wirlich für Security-Aufgaben bei Ubuntu qualifiziert ist. Im Gegensatz zu Amerikanern und deutschen Professoren bin ich nämlich nicht der Meinung, daß persönliche Kritik per se verboten ist. Wenn jemand Fehler macht, die in seiner Person liegen, dann muß auch die Kritik notwendigeweise in diese Richtung zielen. Und wenn mir jemand so etwas auftischt, was von vornherein die Variante des Angriffs negiert, beliebige Dateien auszulesen (und etwas ähnliches gabs ja beim Internet Explorer gerade), dann frag ich schon mal nach, was für einer da hockt.

Seine Antwort (immerhin hat der den Zustand dazu von „invalid” auf das ehrlichere aber nicht bessere „won’t fix” geändert):

I’ll put your personal attack aside and address your point as I think your main question is valid. I would appreciate it if you would discontinue these attacks.

I did not miss your point. The browser is supposed to be able to read and write files from the user’s directory. This is *by design* of the browser, in particular firefox. How else is someone supposed to download a file? To upload their presentation to the company webserver? If the AppArmor profile denied these actions by default, what would the regular user who knows nothing of AppArmor do?

• If we were lucky, they would only turn off only the firefox profile (which, I might add is *opt in* only right now). This action would weaken the security stance of firefox since it would now be running totally unconfined.
• If we were more unlucky, the user would turn off all of AppArmor (this has been seen occasionally with AppArmor but famously with SELinux). The result would be that CUPS, dhclient, evince, the guest-session and other profiles in Ubuntu would be disabled.
• If we were most unlucky, the user would become frustrated with Ubuntu and use another OS, likely complaining to everyone they know about it. Considering all of Ubuntu’s proactive security features (including, but in no way limited to AppArmor) and depending on what OS they choose, this could greatly decrease the security stance for the user.

The browser is arguably the most important application a regular user uses. If we are cavalier about breaking the most used application on the Desktop, then from the user’s point of view the Desktop and OS are broken. We must carefully weigh usability requirements against security protections in all cases, otherwise it leads to frustration and the
security feature being turned off.

AppArmor can protect against many things. The firefox profile protects against execution of arbitrary code by the browser and reading/writing of files you do not own (eg /etc/passwd), reading/writing sensitive files like the user’s gnome-keyring, ssh keys, gnupg keys, history files, swp, backup files, rc files and to files in the standard PATH. It also confines add-ons and extensions to the above. Firefox is integrated into the Desktop and so it must be allowed to open helper programs and access the user’s data. The profile is by default *general purpose* with the design being:

• when enabled, it significantly improves the security of firefox as is
• it provides a starting point for people to confine firefox how they want to
• the implementation gives the user the ability to fine-tune it to be as strict as desired

Of course firefox can be locked down more to protect the user’s data. We could make it so that it could only write to ~/Downloads and read from ~/Public. However, this deviates from upstream’s design, would likely put Ubuntu’s Mozilla branding at stake, and most importantly frustrate users. Is Ubuntu’s profile a “violation of the idea of apparmor”? Of course not — it *is* protecting user’s from various attacks and many forms of information disclosure. It is a distribution requirement to provide a functional browser. It is a distribution choice to not break it with too-aggressive security protections. It is a user’s/administrator’s choice to configure the profile for her environment.

Der kapiert’s nicht.

Es geht nicht darum, die Default-Einstellungen zu verändern und den Durchschnittuser vor für ihn unlösbare Probleme und Frust zu stellen, sondern es geht darum, die Einstellungen für den notwendigen Betrieb von Firefox (Libraries lesen, Konfiguration lesen und schreiben) von den Einstellungen für die Daten, die nichts mit Firefox zu tun haben (wie $HOME, /mnt usw.) zu trennen, damit man sie getrennt anpassen kann ohne mit dem /etc-update-Mechanismus aneinanderzugeraten. Und das mit AppArmor hat er auch nicht richtig verstanden.

Aber die Argumentation muß man sich mal reinziehen:

• Browser würden *by design* Dateien lesen und schreiben. Also geben wir in Zugriff auf einfach alle Dateien, damit sie das auch tun können. Is ja *Design*.

  Daß ein Browser nicht dafür designt ist, alle Dateien abzugrasen, geht nicht in die Birne. Daß ein Browser designed ist, beim Up- und Download vorher einen Dialog anzuzeigen, mit dem der Benutzer das bestätigen muß, während bei vielen Angriffen das Zeug unbemerkt kopiert wird, und das nun wirklich nicht Design ist, geht auch nicht in die Birne. Und daß ein Angreifer Pufferüberläufe usw. ausnutzt, damit der Browser ja eben gerade etwas ganz anderes macht als per Design vorgesehen, und apparmor nicht da ist, um das Design zu unterstützen, sondern Abweichungen vom Design zu unterbinden, geht schon gar nicht in die Birne rein.

• Und dann diese Aussage: Stell Dir vor, man würde die Datei-Rechte einschränken und jemand wollte eine Präsentation auf den Firmenserver hochladen und könnte. Da trieft die Naivität doch geradezu heraus. Genauso könnte man sagen, stell Dir vor, ich habe eine streng vertrauliche Präsentation auf der Platte, und der Angreifer lädt sie sich herunter.

• Und dann diese alles oder nichts-Logik. Nöh, wir machen ein Up- und Download-Verzeichnis. Oder $HOME/Desktop. Wir geben gleich alles frei: /**. Lesen und Schreiben. Vollgas.

• AppArmor soll den Benutzer nicht vor sich selbst schützen. Angreifer? Pufferüberlauf? Zugriffsrechteproblem im Browser? Nie gehört. Der geht tatsächlich davon aus, aß jeder Schreib- und Lesezugriff durch Firefox auf den Benutzer zurückgeht. Daß der Browser mal was anderes treibt als der Benutzer glaubt, kann der sich nicht vorstellen.
• Zitat: AppArmor can protect against many things. The firefox profile protects against execution of arbitrary code by the browser and reading/writing of files you do not own (eg /etc/passwd),

  Das ist Quatsch. AppArmor hängt an den Systemaufrufen. Wenn jemand über einen Pufferüberlauf „arbitrary code” einschleust, schützt AppArmor dagegen nicht. Zwar hat AppArmor auch Zugriffsrechte für Code Execution, das bezieht sich aber auf einen Prozesswechsel über exec(), also das ausführen einer Programmdatei, und nicht auf eingeschleusten Maschinencode.

  Und den Schutz vom Lesen und Schreiben von Dateien, die mir nicht gehören, übernehmen schon die Dateizugriffsrechte und das Betriebssystem. Dazu brauche ich nicht apparmor.

  Das man einen Schutz dagegen braucht, daß der Browser etwas tut, was man nicht will, und was nicht schon durch das Betriebssystem abgefangen wird, hat der gar nicht erst verstanden.

• Und das Problem mit der Änderung von /etc-Dateien hat er auch nicht begriffen.

Da sitzt bei Ubuntu an einer der wichtigsten Sicherheitsstellen – der Webbrowser, wichtiger geht’s kaum, was Netzwerkangriffe betrifft – so eine Tranfunzel. Der hat überhaupt nichts begriffen und hat Ansichten, bei denen man richtig Angst bekommen kann, was die sonst noch für einen Blödsinn treiben. Der hat nicht nur AppArmor nicht begriffen, der hat generell das Prinzip Sicherheit nicht begriffen. Und wie Angriffe funktionieren. Aber kanzelt Leute mit Phrasen ab wie ein Politiker.

Für mich hat das große (gefühlte) Ähnlichkeit mit unserer Löschproblematik bei Wikipedia. Alles was nicht in die eigene ideologische Kleinbürgersichtweise paßt, wird als „invalid” gestrichen.

Da gibt es eine freie, offene Struktur. An der jeder teilnehmen kann. Und weil’s kostenlos sein soll, natürlich auch kein oder wenig Geld für die Macher. Damit holt man sich dann Leute rein, die weder fachlich noch charakterlich geeignet sind, aber sich dann in ihrer (vermeintlichen) Macht hochschaukeln.

Das Dumme daran ist, daß das bei so einer Massendistribution wie Ubuntu oder überhaupt dem Einsatz von Linux wirklich verdammt gefährlich werden kann.

Und es zeigt (und es ist ja kein Einzelfall, auch wenn ich hier nur einen Einzelfall beleuchte), daß der Nachwuchs keineswegs besser ist als die Alten. Die „Digital Natives” sind vielleicht in die Sache reingeboren und halten sie für normal. Verstanden haben sie sie deshalb aber noch lange nicht. Autofahren ist heute auch normal, da ist auch jeder reingeboren. Trotzdem werden Autos immer komplexer und deshalb wären immer weniger Leute in der Lage, ihr Auto selbst zu reparieren.

Wir züchten keine „Digital Natives”. Wir züchten „Digital Naives”.

Und wir haben immer größere Probleme mit der IT Sicherheit. Ubuntu hat offenbar ein ziemliches Kompetenz- und Kapazitätsproblem. (Und die halte ich noch für die derzeit beste Distribution!)