Paketmanagement mit Snap auf Linux-Systemen - Eingeschnappt

Lesezeit
9 Minuten
Bis jetzt gelesen

Paketmanagement mit Snap auf Linux-Systemen - Eingeschnappt

05.01.2018 - 12:00
Veröffentlicht in:

Die Nachteile der herkömmlichen Paketverwaltung unter Linux möchte Ubuntu-Entwickler Canonical mit seinem Paketformat Snap eliminieren. Das bringt allerdings auch gleich ein paar neue Probleme mit, die Administratoren im Alltag kennen sollten.

Im Gegensatz zu Windows und macOS kümmert sich auf Linux-Systemen ein zentraler Paketmanager um die installierte Software. Die in kompakten Paketen ausgelieferten Programme hält ein Repository vor, das der Hersteller der jeweiligen Distribution betreut. Kurze Kommandozeilenbefehle installieren eine Datenbank, löschen den nicht mehr benötigten Ruby-Interpreter und halten vor allem das komplette System auf dem aktuellen Stand. Jedes Paket enthält dabei genau eine Programmkomponente. So stecken beispielsweise der Webserver und die von ihm genutzte OpenSSL-Bibliothek in unterschiedlichen Paketen. Dies hat den Vorteil, dass jede Bibliothek nur einmal auf der Festplatte landet und die Paketverwaltung sie nur an einer Stelle aktualisieren muss.

Abhängigkeiten engen ein

Die Repositories führen allerdings nur einen Teil der für Linux verfügbaren Programme und Bibliotheken, die jeweils nur in einer bestimmten Version vorliegen. Benötigen Anwender eine Software, die im Repository fehlt, müssen sie sie an der Paketverwaltung vorbei installieren. Setzt das Programm weitere Bibliotheken voraus, verheddert man sich als Administrator schnell in den zahlreichen Abhängigkeiten zwischen den einzelnen Paketen. Verlangt das Programm die Bibliotheken sogar in ganz bestimmten Versionen, bleibt oft nur der Ausweg, sie von Hand zu übersetzen und zukünftig selbst auf dem aktuellen Stand zu halten.

Mit etwas Glück stellt der Entwickler die Software als fertiges Paket bereit. Das lässt sich jedoch immer nur auf der Distribution einspielen, für die es der Entwickler geschnürt hat. So funktioniert ein Paket für Debian 8 nicht unbedingt auch unter Debian 9. Ein weiteres Problem sind die zueinander inkompatiblen Paketformate, wenngleich bei den großen Distributionen mittlerweile nur noch Dpkg und RPM eine Rolle spielen.

Außerdem dürfen sich laufende Programme recht weit im Dateisystem umsehen. Selbst wenn die Anwendung mit eingeschränkten Rechten läuft, kann sie in der Regel einen Blick in "/usr", "/tmp" und viele weitere Verzeichnisse werfen. Erhält ein Angreifer über eine Sicherheitslücke Root-Rechte, kann das ferngesteuerte Programm sogar das komplette System umpflügen.

Paketformat mit allem Zubehör

Die genannten Nachteile versuchen gleich mehrere Projekte mit einem runderneuerten Paketmanagementsystem zu eliminieren. Ubuntu-Entwickler Canonical wirft dabei sein selbstentwickeltes Snap-Format in den Ring [1]: Wie beim herkömmlichen Paketmanagement kommen die Anwendungen in kompakten Paketen auf den Rechner. Diese sogenannten Snaps enthalten jedoch neben der eigentlichen Anwendung auch alle zur Ausführung benötigten Komponenten. Das Snap mit dem Webserver bringt folglich auch die von ihm benötigte OpenSSL-Bibliothek in der passenden Version mit. Die in den Snaps ausgelieferten Anwendungen laufen daher auf jeder Linux-Distribution, die Snaps unterstützt. Entwickler müssen folglich nur noch ein einziges Snap-Paket bauen und bereitstellen. Letzteres geschieht entweder über die Homepage des Entwicklers oder ein zentrales Repository, das in der Snap-Welt Store heißt. Da sich Snaps und die Pakete der Distribution nicht in die Quere kommen, dürfen sie Anwender und Administratoren parallel nutzen.

Snappy stammt vom Smartphone
Das Snap-Format geht auf Canonicals Versuch zurück, Ubuntu auf Smartphones zu etablieren. Für diesen Einsatzzweck entwickelte das Unternehmen zunächst das Click-Format. Einige der dort verwendeten Konzepte übernahm Canonical dann in die neue Paketverwaltung Snappy. Sie sollte insbesondere auch auf Geräten für das Internet of Things (IoT) zum Einsatz kommen. Canonical schuf dafür eigens die Ubuntu-Variante "Snappy Ubuntu Core", die aus einem minimalen Ubuntu-System bestand und die Paketverwaltung komplett Snappy überließ. Aus Snappy gingen dann wiederum die heute aktuellen Snaps hervor. Offiziell ist der Begriff "Snappy" mittlerweile verschwunden, die IoT-Distribution heißt nur noch "Ubuntu Core". Dennoch stolpert man im Internet gelegentlich über den Begriff "Snappy".

Die Anwendung in einem Snap läuft immer in einer Sandbox, in der nur die unbedingt nötigen Ressourcen bereitstehen. Insbesondere sieht das Programm nur einige ausgewählte Verzeichnisse, von denen gerade einmal vier Stück den Schreibzugriff erlauben. Darüber hinaus schottet die Sandbox die Anwendung von allen anderen Prozessen ab. Ein Amok laufender Prozess kann somit nicht das System beeinträchtigen.

Unter Ubuntu ist seit der Version 16.04 die Snap-Paketverwaltung vorinstalliert – das gilt insbesondere auch für die Server-Ausgaben. Bei der IoT-Variante Ubuntu Core für Kleinst- und Embedded-Geräte ist Snap sogar die einzig vorhandene Paketverwaltung. Da die Snap-Werkzeuge einer Open-Source-Lizenz unterstehen, lassen sie sich auch auf vielen anderen Distributionen nachrüsten. Bei aktuellen Debian- und Linux-Mint-Systemen genügt etwa sudo apt install snapd, bei Fedora spielt ab Version 25 ein sudo dnf install snapd die notwendigen Tools ein. Installationsanleitungen für weitere Distributionen finden sich unter [2].

Einfache Bedienung

Äußerlich unterscheidet sich Snap kaum von der etablierten Konkurrenz. Ähnlich wie "apt", "zypper" und Co verwaltet das Kommandozeilenprogramm "snap" die Pakete. Der folgende Befehl installiert etwa die Datenbank CouchDB:

sudo snap install couchdb

Standardmäßig zapft "snap" den von Canonical betriebenen Ubuntu Store an. Dort kann jeder Entwickler seine Snaps nach einer Registrierung hochladen. Ähnlich wie im Apple Store oder bei Google Play durchläuft das Snap vor der Veröffentlichung einen automatisierten Review-Prozess. Den kompletten Ubuntu Store durchsuchen Sie mit "snap find" (Bild 1). Während einige Snap-Unterkommandos wie "find" auch Benutzer aufrufen können, gelingt die Installation oder die Deinstallation nur mit Root- beziehungsweise Systemverwalterrechten.

Bild 1: Hier hat Snap alle Pakete herausgesucht, die zum Begriff "database" passen.
Bild 1: Hier hat Snap alle Pakete herausgesucht, die zum Begriff "database" passen.


Ein aus dem Internet heruntergeladenes Snap spielen Sie analog ein, das Snap "foo.snap" etwa mit sudo snap install foo.snap. Sollte "snap" dabei eine fehlende Signatur bemängeln, müssen Sie diese separat herunterladen. Die entsprechende Datei trägt in der Regel die Endung ".assert", die Sie Snap mit sudo snap ack foo.assert zuführen. Anschließend sollte "snap" das Snap-Paket klaglos installieren. Alternativ können Sie das Paket via sudo snap install --force-dangerous foo.snap einspielen. Der Parameter hebelt dabei die Verifikation aus, weshalb die Snap-Entwickler davon abraten.

In jedem Fall verrät snap list alle derzeit installierten Snaps, die wiederum der Befehl sudo snap refresh aktualisiert. Zumindest unter Ubuntu stößt ein entsprechender Systemd-Timer diesen Befehl einmal in der Woche automatisch an. Sollte beim Update eines Snaps ein Fehler auftreten, kehrt sudo snap revert couchdb zur letzten Version vor dem Update zurück – im Beispiel zur letzten CouchDB-Version.

Für Administratoren interessant sind die Kommandos snap disable und snap enable, über die sich ein Snap schnell deaktivieren und später wieder aktivieren lässt. Via sudo snap disable couchdb können Sie so vorübergehend die Datenbank lahmlegen. Der Befehl sudo remove couchdb löscht schließlich das CouchDB-Snap komplett von der Festplatte. Bietet ein Snap einen Dienst an, lässt er sich manuell mit snap start, snap stop und snap restart kontrollieren.

Bild 2: Die Website uApp Explorer führt einen Katalog mit Snaps.
Bild 2: Die Website uApp Explorer führt einen Katalog mit Snaps.


In den Ubuntu Store können Entwickler auch Snaps mit Vorab- oder Testversionen ihrer Software hochladen. Dies soll Anwendern und Administratoren die Möglichkeit geben, das Programm unkompliziert zu testen. Damit Nutzer des Stores nicht versehentlich eine Vorabversion eines Snaps einspielen, bietet der Store vier verschiedene Kanäle an: Standardmäßig holt Snap nur stabile Software aus dem "stable"-Channel. In den Kanälen "candidate" und "beta" liegen die Release Candidates und Beta-Versionen der Software. Schließlich gibt es noch den "edge"-Kanal, in dem Daily Builds bereitstehen. Wenn Sie eine Beta-Version installieren möchten, müssen Sie mit "--channel" explizit in den entsprechenden Kanal wechseln:

$ sudo snap install couchdb --channel=beta

Pakete packen

Entwickler erstellen Snaps mit dem Werkzeug "snapcraft", das die Anwendung und ihre Abhängigkeiten in ein komprimiertes "squashfs"-Dateisystem verpackt. In dem so geschnürten Snap liegt auch immer eine Textdatei "snap.yaml". Sie enthält Metadaten für die Snap-Paketverwaltung, wie etwa eine Beschreibung der Anwendung oder die benötigte Prozessorarchitektur. Des Weiteren bekommt das Snap darin einen Namen, über den die Benutzer später das Programm aufrufen.

Jedes Snap darf zudem mehrere Anwendungen enthalten. Das ist etwa bei Datenbanken wie MySQL nützlich, bei denen das Snap neben dem eigentlichen Datenbank-Daemon auch die verschiedenen Kommandozeilenprogramme enthält. In "snap.yaml" erhält jedes dieser Programme einen eigenen Namen, der nicht mit dem Dateinamen des Binary übereinstimmen muss. Anwender rufen dann die einzelnen Programme über den entsprechenden Namen auf, dem sie zusätzlich den Namen des Snaps voranstellen. Für dieses etwas verwirrende Konzept stellt Canonical mit dem Snap "hello-world" ein einfaches Beispiel bereit, dessen "snap.yaml" Listing 1 zeigt.

Listing 1: Inhalt von snap.yaml für das "hello-world"-Snap

name: hello-world
version: 6.3
architectures: [ all ]
summary: The 'hello-world' of snaps
description: |
      This is a simple snap example that includes a few interesting binaries to demonstrate snaps and their confinement.
      * hello-world.env - dump the env of commands run inside app sandbox
      * hello-world.evil - show how snappy sandboxes binaries
      * hello-world.sh - enter interactive shell that runs in app sandbox 
      * hello-world - simply output text
apps:
    env:
      command: bin/env
    evil:
      command: bin/evil
    sh:
      command: bin/sh
    hello-world:
      command: bin/ech

Nachdem Sie das Snap mit sudo snap install hello-world installiert haben, können Sie die im Snap enthaltene Shell ("bin/sh") mit hello-world.sh starten. Im Gegensatz zu einer normalen per "/bin/sh" gestarteten Shell läuft die so geöffnete Shell in einer abgeschotteten Sandbox. Wenn Sie nur hello-world aufrufen, startet automatisch das Programm, das in "snap.yaml" den gleichen Namen wie das Snap trägt. Im "hello-world"-Beispiel startet folglich "echo". Mit diesem Mechanismus kann der Entwickler unter anderem geschickt verstecken, dass im Hintergrund nicht ein Programm, sondern etwa nur ein Shell-Skript startet.

Eigene Mountpoints für Pakete

Die Verwaltung der Snaps übernimmt der ständig im Hintergrund laufende Daemon "snapd", dem "snap" die passenden Befehle erteilt. Bei der Installation eines neuen Snaps kopiert der Daemon das Snap-Paket in das Unterverzeichnis "/var/snaps". Gleichzeitig mountet er das enthaltene "squashfs"-Dateisystem im Unterverzeichnis "/snap/Name/current", wobei "Name" für den Namen des Snaps steht. Die auch für Administratoren interessante "snap.yaml" finden Sie danach immer unter "/snap/Name/current/meta/snap.yaml". Des Weiteren zeigen unter "/snap/bin" symbolische Links auf die Snaps. Da zumindest unter Ubuntu "/snap/bin" in der Umgebungsvariable "$PATH" eingetragen ist, können alle Benutzer des Systems die Snap-Anwendungen einfach direkt über ihren Namen starten. Sofern das Snap eine Desktop-Datei (".desktop") und ein Icon enthält, bindet sie der Snap-Daemon zudem noch ins Startmenü ein.

Auf das Verzeichnis "/snap/Name/current" kann die Anwendung aus dem Snap aus Sicherheitsgründen nur lesend zugreifen. Jedes Snap besitzt deshalb vier weitere Verzeichnisse, auf die es Schreibrechte besitzt. Das erste im Bunde namens "/var/snap/Name/current/" untersteht der eingebauten Versionsverwaltung: Bei einem Update des Snap sichert der "snapd"-Daemon automatisch den Inhalt dieses Verzeichnisses.

Ein snap revert holt dann nicht nur die alte Version des Snap, sondern auch die Daten zurück. Der Ordner bietet sich folglich für Konfigurationsdateien an. Alle anderen Dateien kann das Snap unter "/var/snap/Name/common/" ablegen, das die Versionsverwaltung ignoriert. Für die Daten und Dokumente der einzelnen Benutzer stehen dem Snap zudem die beiden Verzeichnisse "~/snap/Name/cur-rent/" und "~/snap/Name/common/" zur Verfügung.

Sandbox bringt mehr Sicherheit

Jede gestartete Anwendung läuft in einer Sandbox, die gleich mehrere Sicherheitstechniken einsetzt. So blockieren Seccomp-Filter den Zugriff auf Systemfunktionen des Linux-Kernels. AppArmor wiederum verhindert den Zugriff auf Verzeichnisse. Für die Abschottung gegenüber anderen laufenden Prozessen sorgen Kernel-Namespaces und Cgroups. Die Ubuntu-Kernel bieten zudem noch weitere spezielle Patches, die den Kernel weiter härten sollen.

Bild 3: Abgesehen von den Bibliotheken und Programmen im OS core bringen die Anwendun-gen in den Snaps ihre eigenen Bibliotheken und Frameworks mit.
Bild 3: Abgesehen von den Bibliotheken und Programmen im OS core bringen die Anwendun-gen in den Snaps ihre eigenen Bibliotheken und Frameworks mit.


Als Grundlage für jede Sandbox dient ein spezielles Snap-Paket mit einem minimalen Linux-System. Dieses sogenannte OS-Snap enthält unter anderem die Glibc- und OpenSSL-Bibliotheken sowie Python und Systemd, die (fast) jedes Snap benötigt. Über das Dateisystem des OS-Snap legt das Snap-Paketsystem dann das Dateisystem aus dem normalen Snap (Bild 3). Sobald Sie das erste Mal ein Snap aus dem Ubunut Store herunterladen, wandert auch automatisch einmalig das OS-Snap nach "/snap".

Snaps verbinden

Da die Anwendungen in den Sandboxen abgeschottet laufen, kann ein Datenbank-Client in einem Snap nicht die MySQL-Datenbank aus einem anderen Snap nutzen. Um dies dennoch zu ermöglichen, verwenden die Snaps sogenannte Interfaces: Ein Dienst in einem Snap bietet einen Slot an, mit dem sich andere Snaps über einen Stecker ("Plug") verbinden können. Nur Anwendungen mit dem passenden Interface können miteinander kommunizieren. Im Beispiel könnte die MySQL-Datenbank ein Interface namens "mysql" besitzen, das einen Slot namens "database" anbietet. Die Client-Anwendung wiederum unterstützt ebenfalls das Interface "mysql" und besitzt einen Plug namens "db", der in den Slot "database" passt. Welche Interfaces mit welchen Slots und Plugs ein Snap-Paket anbietet, notiert der Ersteller des Snap in "snap.yaml".

Bild 4: Über Interfaces können Snaps aufeinander zugreifen.
Bild 4: Über Interfaces können Snaps aufeinander zugreifen.


Es gibt mehrere vordefinierte Interfaces, über die sich das Snap unter anderem mit dem gastgebenden Linux-System verbinden darf. So kann etwa über das Interface "network" eine Anwendung als Client auf das Netzwerk zugreifen. Analog lassen sich Server über das Interface "network-bind" erreichen. Einige dieser Interfaces verbindet der "snapd"-Daemon bereits bei der Installation des entsprechenden Snaps. Dies gilt beispielsweise für "network" und "network-bind". Manuell lassen sich zwei Snaps über das Kommando snap connect Snap:Plug Snap:Slot verbinden. Eine Aufstellung aller existierenden Interfaces findet sich unter [3].

Nachteile von Snaps

Snaps klingen erst einmal verlockend, bringen aber selbst Probleme mit. Da in einem Snap alle von der Anwendung benötigten Abhängigkeiten stecken, bläht sich das Snap entsprechend auf. Von mehreren Anwendungen genutzte Bibliotheken landen mehrfach auf der Festplatte. Letztlich sind bei Snaps die Anwendungsentwickler dafür verantwortlich, alle mitgelieferten Bibliotheken auf dem neuesten Stand zu halten. Reagieren die Entwickler nicht schnell und gewissenhaft, können unbemerkt Sicherheitslücken zurückbleiben. Liegt eine Bibliothek in einer neuen Version vor, erzwingt das ein Update aller Snaps, in der sie enthalten ist.

Fällt der "snapd"-Daemon aus, ist das komplette Paketsystem lahmgelegt, er mutiert somit zum Single Point of Failure. Der "snapd"-Daemon kann zudem derzeit immer nur einen Store anzapfen. Standardmäßig ist das der von Canonical betriebene Ubuntu Store, eine Alternative gibt es noch nicht. Wer einen eigenen Store aufsetzen möchte, muss den dazu passenden Server selbst implementieren, die Software hinter dem Ubuntu Store hält Canonical unter Verschluss. Der Quellcode eines minimalistischen Beispiel-Stores lag für einige Zeit auf GitHub. Durch die zahlreichen Änderungen an Snap funktionierte diese Implementierung jedoch nicht mehr, sodass der Entwickler schließlich den Quellcode wieder entfernte. Im Kern handelt es sich bei einem Snap Store um eine einfache Web-Anwendung, die via REST-API die entsprechenden Snaps ausliefert.

Die Zahl der im Ubuntu Store angebotenen Snaps war zum Redaktionsschluss überschaubar. MySQL und viele andere wichtige Anwendungen fehlten, im vorhandenen Programmangebot fanden sich zudem häufig veraltete Versionen. Langfristig möchte Canonical offenbar auch kostenpflichtige Snaps anbieten, zumindest ist "snap" darauf vorbereitet (mit dem Kommando snap buy).

Den vollen Funktionsumfang der Snaps gibt es derzeit nur unter Ubuntu. Auf allen anderen offiziell unterstützten Distributionen ist zumindest der sogenannte Devmode aktiv. Verletzt in ihm eine Anwendung eine Sicherheitsregel, produziert das lediglich eine Warnung im Syslog. App­Armor setzen zudem nicht alle Distributionen ein, die speziellen Patches von Canonical zur Härtung des Linux-Kernels gibt es auch nur für Ubuntu.

Fazit

Die Snaps sind nicht der einzige Versuch, das Paketmanagement zu reformieren. Größter Konkurrent ist derzeit Flatpak, das unter anderem Fedora favorisiert. Es setzt zwar ebenfalls auf das Sandbox-Prinzip, unterscheidet sich aber von Snaps in vielen Details.

Unter Ubuntu und dessen Derivaten ergänzen Snaps mittelfristig das bestehende Debian-Paketsystem. Aufgrund der vielen Nachteile dürften Snaps die Dpkg-Pakete jedoch nicht komplett ersetzen. Das gilt insbesondere in der Cloud und ähnlichen Bereichen, die schlanke Betriebssystem-images bevorzugen. Auf dem Desktop und dem Server stellen sie eine interessante Ergänzung dar, wobei insbesondere auf dem Server eine starke Konkurrenz durch Docker droht.

(of) Author: Tim Schürmann

Aus dem IT-Administrator Magazin Ausgabe 1/2018: Softwareverteilung & Patchmanagement Seite 82-85

Link-Codes

[1] Snap: https://snapcraft.io/

[2] Installationshinweise: https://docs.snapcraft.io/core/install/

[3] Snap-Interfaces: https://docs.snapcraft.io/reference/interfaces/

 

Ähnliche Beiträge

Mit Windows Clients auf Linux Server zugreifen

Der Remote-Desktop-Zugriff zwischen Windows und Linux verbraucht normalerweise eine ganze Menge Bandbreite, Zeit und Nerven. Wäre es nicht schön, wenn Windows-Benutzer genauso einfach grafisch auf Linux-Systeme zugreifen könnten wie auf andere Windows-Maschinen, und zwar am besten noch mit ein und derselben Anwendung. Mit Xrdp, das dieser Artikel näher vorstellt, rückt dieses Ziel in erreichbare Nähe.

Im Test: Heimdal Patch & Asset Management

Ein zeitgemäßes Patchmanagement darf sich angesichts der vielfältigen Bedrohungen nicht allein auf die Microsoft-Produkte konzentrieren, sondern muss sich auch verbreiteten Drittanbieteranwendungen widmen. Der dänische Anbieter Heimdal Security geht noch einen Schritt weiter und hat eine ganze Suite zum Schutz vor Cyberbedrohungen im Programm. Mit dem Fokus auf das Patchen haben wir uns das cloudbasierte Angebot genauer angesehen.

Im Test: Kasm Workspaces 1.14.0

Zur Bereitstellung zahlreicher Sitzungen in großem Maßstab setzen die bekannten Anbieter von Desktopvirtualisierung auf verschiedene Methoden der Provisionierung, die viele gleichartige Maschinen aus einem Golden Image starten und nach der Verwendung wieder recyceln. Doch abseits der Multisession-Variante von Windows 10 und 11, die Microsoft zudem exklusiv in Azure anbietet, nutzt jeder Desktop eine ausgewachsene VM als Basis. Warum diese Vorgeschichte?