Veni, Vidi, VISA

Hier habe ich schonmal dazu ausführlich Stellung zu meiner Aussage "[...] allein schon deswegen damit ich nicht ständig *BSD anstelle von Linux installieren muss [...]" bezogen, aber anscheinend reicht das immer noch nicht. Einige Debian-Nazis haben mir nämlich u. a. via Mail erklärt das ich keine Ahnung habe und Müll labere, weil Die Sicherheit eines System in erster Linie vom Administrator abhängt.
Nun.. das ist nur die halbe Wahrheit. Es ist korrekt das ein fachlich versierter Admin das gleiche System "sicherer machen kann" als ein Anfänger. Nur ist auch der kompetenteste Admin an das System gebunden. Linux - respektive die Distributionen - sind nicht nach TCSEC evaluiert. Das ist zwar rein theoretisch mit SEL realisierbar, aber mir persönlich ist noch kein einziger Fall bekannt wo das auch gemacht wurde. Und dazu kommen wir gleich zum nächsten Punkt: Nur weil ein System den Vorgaben eines TCSEC/ITSEC-Levels entspricht, ist es noch lange nicht zertifiziert. Das kann nur das BSI. Von daher ist meine Aussage "$FOO ist ein Hochsicherheitssystem und $BAR nicht" vollkommen korrekt. Egal wie sehr das meine lieben Debian-Trottel nervt.

Und nur damit wir uns richtig verstehen: Mit Debian-{Trottel,Nazis} meine ich die "Debian ist krass stabil!" und "Nur für Profis!"- Rumschreier die seit zwei Jahren mit Linux arbeiten und denken sie hätten Ahnung wovon sie reden.


Ahso.. bin vorhin von einem Kurztrip nach Italien zurückgekommen. Einige Fische gefangen, braun geworden, Spaß gehabt und für diesen Herbst nach Spanien zum fischen eingeladen worden.

Letzte Woche war ich bei $Firma und musste dort ins. vier Server neu aufsetzen. Also eigentlich sollte ich dort lediglich einen Server aufsetzen und auf den anderen drei nur die "Betriebssystembedingten Fehler" beheben.

Beim 1. Server mit OpenBSD 4.7 funktionierte kaum ein Port, weil "das wahrscheinlich ein Bug im Compiler ist". Der Compiler war auch schuld. Wieso zickt der rum nur weil man OpenBSD 4.7-STABLE hat und die Ports von -DEVEL einsetzt? Frechheit das!!11!
Server Nr. 2 mit Debian wheezy/sid (auf einer Produktionsplattform wohlgemerkt!) "verhält sich komisch" und hat nicht jeden Daemon gestartet. Naja.. wenn man unter /etc/default/* nicht ENABLE, ACTIVATE, .. anpasst, dann is das halt mal so. Immerhin macht das System das, zu was man es anweist und nicht das was man will.
Server Nr. 3 (ebenfalls wheezy/sid) war schon etwas hartnäckiger. Da konnte man sich nämlich nicht mehr als root einloggen. Als mir der Admin erklärt hat was er gemacht hat, hat es mich eher verwundert das die Kiste nicht gleich explodiert ist. Weil: Sich als root einloggen ist pöhse[TM]. Da hat er ja auch recht. Aber er wollte dafür sorgen das sich niemand mehr als root einloggen kann und hat die Loginshell für root auf /bin/false umgebogen und dafür die /etc/passwd editiert. Und weil er grad dabei war, hat er auch gleich die notwendigen User angelegt, die sich auf der Kiste einloggen können sollten (Ja. Ich weiß.. meine Grammatik saugt); das hat er ebenfalls mit einem Editor gemacht. Ich weiß zwar nicht wie man auf die Idee kommt - und das sauge ich mir jetzt nicht aus den Finger! - in der /etc/shadow die Passwörter für die User mit einem Editor einzutragen. Und zwar im Klartext!

Ich glaube ich muss eine neue Kategorie Namens "Best of pebkac" erstellen, weil langsam aber sicher nimmt das ungeahnte Ausmaße an.

Vorhin auf meiner wheezy/sid - Kiste:

$ apt-get dist-upgrade                                                                                         

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Calculating upgrade... Done

The following NEW packages will be installed:

  libgnutlsxx26 libpipeline1

The following packages will be upgraded:

  anthy anthy-common apt-file avahi-daemon bash-completion cups cups-bsd cups-client cups-common cups-ppdc cupsddk dbus dbus-x11 dhcp3-client dhcp3-common fancontrol google-chrome-beta groff-base hal iproute

  isc-dhcp-client isc-dhcp-common iso-codes libanthy0 libatasmart4 libavahi-client3 libavahi-common-data libavahi-common3 libavahi-core7 libavahi-glib1 libcups2 libcupscgi1 libcupsdriver1 libcupsimage2

  libcupsmime1 libcupsppdc1 libdbus-1-3 libgeoip1 libglew1.5 libgnomevfs2-0 libgnomevfs2-common libgnomevfs2-extra libgnutls-dev libgnutls26 libgpg-error-dev libgpg-error0 libhal-storage1 libhal1 libmms0

  liborc-0.4-0 libpciaccess0 libsensors4 libusb-0.1-4 libusb-dev libvpx0 libx11-6 libx11-data libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-render0 libxcb-shape0 libxcb-shm0 libxcb-xv0 libxcb1 libxext6 libxi6 libxt6

  lm-sensors login man-db mesa-utils myspell-en-us passwd patch pm-utils rsyslog tasksel tasksel-data ttf-dejavu ttf-dejavu-core ttf-dejavu-extra ttf-freefont ttf-liberation usbutils

85 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.

Need to get 59.0 MB of archives.

After this operation, 4,917 kB disk space will be freed.

Do you want to continue [Y/n]? n

Abort

$ aptitude dist-upgrade

The following NEW packages will be installed:

  libgnutlsxx26{a} libpipeline1{a} 

The following packages will be REMOVED:

  fancontrol{u} lm-sensors{u} 

The following packages will be upgraded:

  anthy anthy-common apt-file avahi-daemon bash-completion cups cups-bsd cups-client cups-common cups-ppdc cupsddk dbus dbus-x11 dhcp3-client dhcp3-common google-chrome-beta groff-base hal iproute 

  isc-dhcp-client isc-dhcp-common iso-codes libanthy0 libatasmart4 libavahi-client3 libavahi-common-data libavahi-common3 libavahi-core7 libavahi-glib1 libcups2 libcupscgi1 libcupsdriver1 libcupsimage2 

  libcupsmime1 libcupsppdc1 libdbus-1-3 libgeoip1 libglew1.5 libgnomevfs2-0 libgnomevfs2-common libgnomevfs2-extra libgnutls-dev libgnutls26 libgpg-error-dev libgpg-error0 libhal-storage1 libhal1 libmms0 

  liborc-0.4-0 libpciaccess0 libsensors4 libusb-0.1-4 libusb-dev libvpx0 libx11-6 libx11-data libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-render0 libxcb-shape0 libxcb-shm0 libxcb-xv0 libxcb1 libxext6 libxi6 

  libxt6 login man-db mesa-utils myspell-en-us passwd patch pm-utils rsyslog tasksel tasksel-data ttf-dejavu ttf-dejavu-core ttf-dejavu-extra ttf-freefont ttf-liberation usbutils 

The following packages are RECOMMENDED but will NOT be installed:

  geoip-database libatm1 

83 packages upgraded, 2 newly installed, 2 to remove and 0 not upgraded.

Need to get 58.8 MB of archives. After unpacking 5,519 kB will be freed.

Do you want to continue? [Y/n/?] n

Abort.

Aber für was hab ich denn meine glorreiche helpme()? Ebend.

$ helpme "Soll ich wirklich aptitude verwenden?"

Please wait.. i'll think about..

...Yes!

Diese Frage wurde mir per Mail gestellt und auf meine Aussage [...] allein schon deswegen damit ich nicht ständig *BSD anstelle von Linux installieren muss [...] und meinen Rant gegen Debian 6.0 "Squeeze" verwiesen.
Die meisten Firmen wollen vorzugsweise das System, das sie in der restlichen Umgebung einsetzen (bis auf einige Ausnahmen) und das ist zum Großteil Linux, wobei leider nur sehr wenig Linux auf Workstations einsetzen. Ich werde i. d. R. auch nicht dafür bezahlt eine Workstation für eine Sekretärin oder einen Desktop für einen CADler aufzusetzen und kann auch nur Empfehlungen aussprechen was das OS betrifft. Am häufigsten wurde bisher Debian eingesetzt; aber nicht weil extremst Stabil und so, sondern weil es schnell zu installieren ist und eine umfangreiche Paketsammlung enthält. Außerdem kann man es am besten verkaufen, weil es den Ruf einer "Profidistribution" hat und auf vielen Architekturen läuft. NetBSD fristet bei meiner Arbeit (leider) ein Nischendasein (letztes Jahr genau dreimal installiert/konfiguriert); Free- und OpenBSD kamen häufiger zum Einsatz, wobei die zum Teil auch als "Auswahlsystem" bei Vservern genutzt wurden.
Sobald es sich allerdings um hochsichere Systeme dreht, rate ich jedem von Linuxdistributionen ab weil der Aufwand den Nutzen übersteigt. Bei *BSD hat man den Vorteil das man alles aus einer Hand bekommt; sprich: Kernel und Userland. Bei Linux wird der Kernel unabhängig von der Distribution entwickelt und deswegen dauert es auch länger bis Bugfixe in die Distribution einfließen (was durch das Fehler einer offiziellen Announce seitens @kernel.org zusätzlich noch verzögert wird). Dazu kommt noch das z. B. Debian Probleme provoziert; ist zwar jetzt etwas reißerisch geschrieben, aber sinngemäß. Bei "lenny" wurde die Verwendung von aptitude(8) empfohlen, während man ein Release später - also "Squeeze" - wieder apt-get(8) für die interaktive Paketverwaltung empfohlen wird. Ich wage mal zu behaupten, dass ich dieses Jahr des öfteren mit Systemen zu tun haben werde, die aufgrund der abwechselnden Nutzung von apt-get(8) und aptitude(8) kaputtoptimiert wurden. Dazu kommt noch das die Backports jetzt offizieller Bestandteil von Debian sind und Nutzer dazu motiviert werden auf diese zurückzugreifen, obwohl in der Vergangenheit in Foren, Newsgroups, Mailinglisten, .. davor gewarnt wurde Stable, Unstable und Testing zu mischen. Ich habe im Laufe der Zeit schon einige Male "aber das stand so auf der Homepage!" gehört wenn ich gefragt habe wieso $FOO $BAR gemacht hat (nicht nur in Bezug auf Debian).
Einige Firmen sind sich dessen auch bewusst, aber nehmen das Risiko in Kauf, weil sie in ihrem Umfeld eine bestimmte Software aus dem aktuellen Branch benötigen, die über das Paketmanagement verwaltet werden kann. Gentoo kommt nur in Ausnahmefällen zum Einsatz, weil jegliche Software aus den Sourcen kompiliert werden muss und die Ressourcen zum Teil anderweitig benötigt werden. Zu guter Letzt kommt es auch darauf an welche Hardware eingesetzt wird. Auch wenn *BSD noch so gut für den Einsatzzweck geeignet gewesen wäre, bringt es nichts wenn die Hardware nicht unterstützt wird. Das ist wieder ein Punkt für Linux, da hier Treiber für mehr (und auch neuere) Geräte vorhanden sind. Lustig wird es dann erst bei proprietären Treibern bzw. Software die einige Distributoren aus Lizenzgründen als proprietär einstufen.
Bei "richtigen" Hochsicherheitssystemen kommt dann allerdings kein Linux oder *BSD zum Einsatz, sondern da werden nach TCSEC evaluierte Systeme wie Trusted Solaris, Ultrix, HP-UX oder AIX eingesetzt.

Und zwar am 06. Januar 2011. Mit einem 13 Monate altem Kernel, Firefox 3.5.16 (3.6.13 ist Stable) und einigen - verständlicherweise nicht ganz aktuellen - Paketen. Alles zwecks Stabilität und so. Nur wieso dann z. B. Developerversionen von Mutt, Slrn, zsh, .. ebenfalls enthalten sind konnte mir leider noch niemand erklären.
Und bevor sich jetzt hier wieder diverse Debian-Nazis auskotzen: Ja. Meine Kunden (ich auch) legen Wert auf aktuelle Software; auch im Serverbereich. Und mir braucht niemand erzählen das das gesamte System instabil wird wenn man aktuelle (!= Devel/Beta) Software ins Paketmanagementsystem einfließen lässt. Was feiert man eigentlich auf den Release Partys? Das es nach zwei Jahren geschafft wurde ein System mit der Software von vor zwei Jahren auszuliefern?

Nachdem ich im vorherigen Eintrag geschrieben habe das ich nicht ständig *BSD anstelle von Linux installieren muss wenn es sich um sicherheitsrelevante Systeme dreht, haben mich schon einige Mails erreicht wo mir erklärt wurde, das man auch Linux auf solchen Systemen verwenden kann.
Stimmt auffallend. Die Frage ist nur ob man das auch wirklich will? Das kein System wirklich sicher ist, steht außer Frage (mal XTS-400 und diverse TCSEC-B1 - Systeme mal außer Acht gelassen) und das Sicherheitslücken gefunden werden lässt sich bei komplexen Systemen nicht vermeiden. Aber was ein absolutes KO-Kriterium sein kann, ist, wie auch gefundene Sicherheitslücken reagiert wird. Bei *BSD (damit ich mich auch den vorherigen Eintrag beziehe) gibt es dafür Mailinglisten und Advisories auf der Homepage wo man sich informieren bzw. auf dem laufenden halten kann. Bei Linux gibt es weder noch; nur einen kurzen Log im git-log. Gut.. besser als nix werden sich jetzt einige denken, aber das ist für Admins alles andere als auch nur irgendwie brauchbar. Ein Admin hat i. d. R. keine Zeit um sich ein Repo zu clonen und dort in den Shortlogs nach Änderungen Ausschau zu halten die sich auf Sicherheitslücken beziehen. Und - auch wenn ich jetzt einige enttäuschen muss - es bringt auch nicht viel das z. B. Debian die Mailingliste debian-security-announce@ hat, wo man über Sicherheitslücken benachrichtigt wird. Deren Aufgabe ist es, Patche über ihr Paketmanagementsystem verfügbar zu machen, damit sie eingespielt werden können. Aber das können sie erst, nachdem der Patch auch verfügbar ist.
Wenn eine bekannte Sicherheitslücke über zwei Monate lang nicht behoben wird, dann ist das absolut untragbar und die Tatsache das in keiner Art und Weise veröffentlicht wird, dass es sich um die Behebung eines sicherheitsrelevanten Bugs handelt, ist für mich ein Grund meinen Kunden Linux auf sicherheitsrelevanten Systemen als letzte Möglichkeit zu empfehlen (und selbst da nur mit Einschränkungen).

Wenn sich Debian/testing ein update/dist-upgrade mit folgender Fehlermeldung quittiert:

Errors were encountered while processing:

 linux-image-2.6.32-5-686

 linux-image-2.6-686

E: Sub-process /usr/bin/dpkg returned an error code (1)

A package failed to install.  Trying to recover:

Setting up linux-image-2.6.32-5-686 (2.6.32-15) ...

Running depmod.

Running update-initramfs.

update-initramfs: Generating /boot/initrd.img-2.6.32-5-686

initrd.img(/boot/initrd.img-2.6.32-5-686

) points to /boot/initrd.img-2.6.32-5-686

 (/boot/initrd.img-2.6.32-5-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-5-686.postinst line 400.

vmlinuz(/boot/vmlinuz-2.6.32-5-686

) points to /boot/vmlinuz-2.6.32-5-686

 (/boot/vmlinuz-2.6.32-5-686) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.32-5-686.postinst line 400.

Running update-grub.

User postinst hook script [update-grub] failed to execute: No such file or directory

dpkg: error processing linux-image-2.6.32-5-686 (--configure):

 subprocess installed post-installation script returned error exit status 255

dpkg: dependency problems prevent configuration of linux-image-2.6-686:

 linux-image-2.6-686 depends on linux-image-2.6.32-5-686; however:

  Package linux-image-2.6.32-5-686 is not configured yet.

dpkg: error processing linux-image-2.6-686 (--configure):

 dependency problems - leaving unconfigured

Errors were encountered while processing:

 linux-image-2.6.32-5-686

 linux-image-2.6-686

Reading package lists... Done

Building dependency tree

Reading state information... Done

Reading extended state information... Done

Initializing package states... Done

Reading task descriptions... Done

dann hilft es nichts zu beteuern das man schon Jahrzehnte lang mit Linux arbeitet und sonst immer jedes Problem lösen konnte und das garantiert ein schwerwiegender Bug von Debian sein muss. Da sollte man einfach nur die Fehlermeldung lesen, feststellen das update-grub nicht vorhanden ist, das mit apt-file search update-grub suchen und dann das Paket mit aptitude(8) installieren.
Die geballte Fachkompetenz einiger Admins treibt mir regelmäßig Tränen in die Augen und das Essen aus dem Magen.

$USER: Ich hab außer unserem Update-Skript wirklich nix angeklickt und trotzdem kommen beim Start von jedem Programm lauter Fehlermeldungen!
$ME: (cat update-skirpt -> enthält nur ein sudo apt-get update ; sudo apt-get upgrade)
$USER: Das Skript hat unser Admin so geschrieben, weil wir einige aktuelle Programme brauchen.
$ME: (cat /etc/apt/sources.list enthält nur unstable)
(Als ich dann dem User erklärt habe das unstable seinen Namen nicht ganz zu unrecht trägt, weil da doch mal was Unstable sein kann, kam ein verwunderter Blick und die Erklärung überhaupt:)
$USER: Unser Admin hat gesagt das er nur die Software aktualisiert und nicht das System!

Zuerst hab ich gedacht das das mal wieder eine Ausrede ist, aber ich hab dann auf anderen Workstations genau das gleiche Skript gesehen und von den Usern die exakt gleiche Erklärung bekommen. Der Admin ist latürnich nicht da, sondern im Urlaub.
Manchmal glaub ich wirklich das die das alles mit Absicht machen. Bastarde!

$Sekretärin kommt mit einem USB-Stick zu uns in den Serverraum und fragt den Admin ob er (man halte sich fest!) "schnell ein LaTeX-Paket auf ihrer Workstation installieren kann, damit sie schönere und ausführlichere Diagramme erstellen kann.
Auf meine Nachfrage als er wieder da war, hat er mir erklärt das den Sekretärinnen die Wahl des Betriebssystems selbst überlassen bleibt, solange es keine Nachteile bringt und sie schon seit einigen Jahren nur mit LaTeX arbeitet. Zwar auf Debian, aber aber wayne.. dafür hat sie einen durchaus knackigen Hintern und das gleicht es wieder aus :>

Sozusagen die Klickibunti-Variante von Die wichtigsten Linuxdistributionen im Detail... Nich austicken. Ich will doch nur spielen :>













(via Email)