oreissig's Unix-Rant

Im Übrigen schafft Gentoo das recht gut mit den Paketsubversionen, wenn die parallel installierbar sind ists meistens geslottet, z.B. sys-boot/grub:0 und sys-boot/grub:2 – wobei letzteres mit USE="-multislot" dann auch DEPEND="!sys-boot/grub:0" hat (d.h. wenn das Useflag multislot nicht gesetzt ist, heißen die Binaries grub-* anstatt grub2-* und GRUB Legacy kann nicht mehr installiert werden).
Gentoo ist aber nicht direkt ein Kackboon-Desktop-System.
Und durch die ganzen eclasses sind die ebuilds bei einfachen Paketen auch einfach, z.B. für einfaches CMake, Autotools, setup.py gibts dann inherit autotools und wie das heißt und damit hat mans im Prinzip schon.

Revisiting How We Put Together Linux Systems

Interessanter Blogpost der ebenfalls die problematische Aspekte des aktuellen Paketmanagement-Ansatz bespricht. Steht sehr viel ähnliches drin wie in diesem Thread. Er meint ebenfalls, dass der "Toolbox"-Ansatz, also Paket-Repositories, wo sich die User selber einen Werkzeugkkasten für ihre Verwendung zusammenstellen, der Realität nicht gerecht wird.

Grundthesen:

• Auf vielen Linux-Installationen in der Realität werden selten einzelne Pakete aktualisiert/installiert, sondern direkt gleiche ganze Builds ausgerollt (Workstation in Unternehmen/Schulen, Server, Embedded-Kisten).
• Benutzer wollen ein App-Model mit schnellen Releases, und nicht erst auf den nächsten Build/Release warten.
• Aktuelle Lösungsansätze (Ubuntu Apps, Docker, ChromeOS) lösen nur einzelne Teilprobleme.

Der Lösungsansatz der präsentiert wird ist dann relativ umfangreich und detailliert. Kern-Idee ist es aber das Dateisystem in Dateisystem-Images aufzuteilen, die dann einzeln kombiniert werden können.

Nebst Low-Level Dateisystem-Images von Distributionen soll es dann Framework-Images z.B. für GNOME geben. Und Vendors wie Mozilla können dann App-Images z.B. für Firefox bauen, die auf der GNOME-Runtime aufbauen, anstatt auf einer spezifischen Distribution.

Home-Verzeichnisse sollen auch so verwaltet werden. Es ist ein ziemlich umfangreicher Vorschlag, aber klingt definitiv interessant. Soll technisch auf btrfs aufbauen, benötigt also Mounting/Snapshotting/Subvoluming um den Sandbox-Ansatz umzusetzen. Und halt ordentliches IPC via kdbus, da das Dateisystem nicht mehr so einfach als Kommunikationsmittel missbraucht werden kann.

Trotzdem soll da ganze Legacy-kompatibel bleiben.

Auja, ich liebe solche Threads (den inkorrekten Apostroph im Thread-Titel hingegen nicht).

Ich beurteile das ganze aus der Sicht eines gewissen Liebhabers der Unix-Philosophie und zugegebenermaßen auch leicht bis mittelstark religiös anmutender Abneigung gegenüber Windows, das muss ich eingestehen.

Insbesondere möchte ich auf das Config-Chaos eingehen. Ansich finde ich es ja nett, dass man unter Unix (Begriff hier allgemein stellvertretend für unixoide Systeme oder Linux-Distributionen) jede Software auch jenseits ihrer selbst mit einem Editor konfigurieren kann. Das schafft eine gewisse Einheitlichkeit. Diese hört aber bereits dann auf, wenn man feststellt, dass Software A ihre Konfiguration als ~/.foo ablegt, Software B als ~/.foorc, Software C ein eigenes Directory erstellt und Software D lieber irgendwo unter ~/.config/… geht. Aber das ist ja noch nicht das Schlimste. Software A verwendet XML (z.B. Pidgin), Software B verwendet ein Variable=Wert-Paar und Software C benutzt C-ähnliche Syntax mit geschweiften Klammern (z.B. nginx). Als vierte Variante seien noch doppelpunktgetrennte Werte à la /etc/passwd oder /etc/group genannt.

Diese Uneinheitlichkeit setzt sich auch als Nebenwirkung der Unix-Philosophie innerhalb der Software selbst fort. An sich ist es ja löblich, dass jede Software einen eigenen Zweck hat und ausschließlich diesen verfolgt. Oftmals ist man dadurch aber gezwungen, Software mit unterschiedlicher, also uneinheitlicher Bedienung zu benutzen – von unterschiedlicher Handhabung von Kommandoparametern bis hin zu uneinheitlichen Keyboard-Shortcuts in curses-Anwendungen. Manchmal gibt es --parameter mit einer zusätzlichen Abkürzung -p, manchmal aber auch -parameter oder in Anlehnung an tar einfach nur einen einzigen Buchstaben. Manche curses-Anwendungen mögen einen Buchstabentastendruck, manche möchten über F-Tasten gesteuert werden und wieder andere wollen eine Strg-Kombination.

Zum Softwareverwaltungsproblem: Wer ist modularer? Windows speichert eine Software mit ihren Bestandteilen an einem zentralen Punkt unter C:\Program Files. Unix flechtet die Software ins System ein. Tatsächlich hat die Windows-Lösung einen gewissen Reiz: Gehe ich in ein Unterverzeichnis unter C:\Program Files, weiß ich ganz genau ›Ich bin genau dort, wo alles ist, was mit der Software zu tun hat‹ und sehe die einzelnen Bestandteile und kann auch die Größe der Software beurteilen. Der Unix-Ansatz macht einen Paketmanager (insbesondere in Zeiten von Shared Libraries) unabdingbar. Man kann ihn als Hilfsmittel zur Softwareverwaltung sehen, aber auch als Versuch, irgendwie den Überblick über die Bestandteile des Systems nicht zu verlieren, also genau das nachzubilden, was im Design eines Windows-Systems von Haus aus im Dateisystem implementiert ist. Ich weiß nicht, ob mein Paketmanager seinen Job so erledigt, wie ich das möchte. Ich hoffe einfach drauf. Genauso wie ich bei einer Deinstallation einer Software unter Windows darauf hoffe, dass wirklich alle Spuren an allen Stellen beseitigt sind, denn dort wiederum entstehen mitunter Hinterlassenschaften in der Registry, im Startmenü und vielleicht noch an anderen Orten. Also eigentlich nimmt sich da nicht viel, oder?

Zitat von gandro

Revisiting How We Put Together Linux Systems

Interessanter Blogpost der ebenfalls die problematische Aspekte des aktuellen Paketmanagement-Ansatz bespricht.

Zusammenfassung von Golem ist jetzt Online: http://www.golem.de/news/lennart-p…409-108941.html

(Drepper und Poettering in einem Thread. Ich warte nur noch auf Ad Hominem :D)

ASLR und das limitiertere Tooling finde ich schon signifikante Nachteile. Die static linux Leute haben da natürlich ne andere Meinung zu: http://sta.li/faq

Die ganzen Steam-Spiele unter Linux machen ja eh den Kompromiss dass sie zwar dynamischen Linken, aber wie unter Windows einfach alle Bibliotheken selber mitbringen (gut, bei Spielen ist da eh häufig ein gepatchtes SDL mit dabei, von daher ist das nicht immer freiwillig).

Ich glaube auch nicht dass statisches Linken alle besprochenen Probleme löst, glaube da braucht es schon noch mehr Abkapselung.

Nachtrag: Same-Frame-Merging ist nicht standardmässig aktiv. Gibt da da auch Security-Bedenken, da es Sidechannel-Attacken erlaubt (man kann durch Timing-Attacken ziemlich zuverlässig rausfinden, ob bestimmte andere Binaries im RAM sind).

Zitat von gandro

Nachtrag: Same-Frame-Merging ist nicht standardmässig aktiv. Gibt da da auch Security-Bedenken, da es Sidechannel-Attacken erlaubt (man kann durch Timing-Attacken ziemlich zuverlässig rausfinden, ob bestimmte andere Binaries im RAM sind).

Hast du da ein Paper zu?

Zitat von CHRiSNEW

Hast du da ein Paper zu?

https://staff.aist.go.jp/c.artho/papers…2011-suzaki.pdf

Sie haben vom aus einem VM-Guest heraus via Copy-on-Write ziemlich zuverlässig herausfinden können, ob im anderen VM-Gast ein Apache oder Firefox-Binary geladen war.

Zitat von gandro

https://staff.aist.go.jp/c.artho/papers…2011-suzaki.pdf

Sie haben vom aus einem VM-Guest heraus via Copy-on-Write ziemlich zuverlässig herausfinden können, ob im anderen VM-Gast ein Apache oder Firefox-Binary geladen war.

Danke! Schon krass.

Zitat von oreissig

wobei der anwendungsfall jetzt für ne installation ohne virtualisierung wurst ist, da kann das programm auch einfach ps ausführen um rauszufinden, welche executables geladen sind...

Offenbar nicht:

[0 running job(s)] {history#1455} 14:32:14 2014-09-08
qsuscs@sculptor ~ 
% pstree
?───tmux─┬─zsh───htop
         └─3*[zsh]
[0 running job(s)] {history#1456} 14:32:15 2014-09-08
qsuscs@sculptor ~ 
% ps aux 
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
qsuscs    1412  0.0  0.0 137152  2152 pts/10   Ss   Jul23   0:08 zsh
qsuscs    3398  0.5  0.0 113320  2256 pts/10   S+   Aug05 270:11 htop
qsuscs    8118  0.0  0.0   3944   292 ?        S    Jun05   0:00 multilog t s999999 n20 !/usr/bin/xz /home/qsuscs/var/log/git-daemon
qsuscs   10270  0.0  0.0   3932   296 ?        S    Jun05   0:02 supervise git-daemon
qsuscs   10271  0.0  0.0   3932   296 ?        S    Jun05   0:00 supervise log
qsuscs   13011  0.0  0.0 137232  2268 pts/13   Ss+  Jul28   0:02 zsh
qsuscs   14720  0.0  0.0  28228  3432 ?        Ss   Jul21  30:03 tmux
qsuscs   14721  0.0  0.0 140068  2992 pts/8    Ss+  Jul21   0:05 zsh
qsuscs   15976  0.0  0.0 161124 11928 ?        S    08:00   0:00 /package/host/localhost/php-5.4.11/bin/php-cgi
qsuscs   21306  0.0  0.0   4104   364 ?        S    Jun05   4:08 /command/svscan /home/qsuscs/service
qsuscs   28273  0.0  0.0 139412  2412 pts/14   Ss+  Jul27   0:01 zsh
qsuscs   29089  4.4  0.0 141900  3876 pts/15   Ss   14:32   0:00 -zsh
qsuscs   30677  0.0  0.0 110240  1084 pts/15   R+   14:32   0:00 ps aux
qsuscs   32726  0.0  0.0  16312   592 ?        S    Jul27   0:00 /home/qsuscs/bin/git daemon --port=63913 --base-path=/home/qsuscs/git --listen=95.143.172.183 --listen=2001:1a50:11:0:5f:8f:acb7:d8 --verbose
qsuscs   32729  0.0  0.0  15348   732 ?        S    Jul27   0:00 git-daemon --port=63913 --base-path=/home/qsuscs/git --listen=95.143.172.183 --listen=2001:1a50:11:0:5f:8f:acb7:d8 --verbose /home/qsuscs/git

Da sind definitiv noch andere Prozesse am laufen, die seh ich aber nicht.

Zitat von oreissig

wobei der anwendungsfall jetzt für ne installation ohne virtualisierung wurst ist, da kann das programm auch einfach ps ausführen um rauszufinden, welche executables geladen sind...

In dem Paper präsentieren sie auch nen Experiment wo sie auch eine über HTTPS heruntergeladene Datei erkennen können.

Prozess-Erkennung war das einfachste, weil sich das Mapping der Binaries auf Pages relativ deterministisch verhält, der Angriff lässt sich aber auch für andere Informations-Leaks nutzen. Theoretisch lassen sich Anwendungen knacken die darauf basieren dass Daten im nur im virtuellen Addressraum der Applikation lesbar sind, jedoch nicht von anderen Prozessen aus.

Nachtrag: Rein von der Angriffsidee her könnte ich mir sogar ein Experiment vorstellen wo man so eine Attacke via Javascript ausführt. In der Praxis vermutlich schwierig zu kontrollieren, aber wäre Prozess-Probing dann wieder ein ernsthaftes Problem.