Ich nutze Linux schon seit vielen Jahren. Zuerst Kubuntu, Lubuntu. Dann später KDE Neon. Und seit ich bei OpenSUSE LEAP gelandet bin, habe ich die für mich ideale Distribution gefunden. Aber obwohl ich jetzt seit Jahren Linux nutze, ist mir erst jetzt bewusst gewesen, dass mein Linux-System von zB Microsoft jederzeit übernommen oder gekillt werden kann. Warum? Weil ich für dauernde Teams-Meeting-Einladungen gezwungen war, Microsoft Edge in der Linux-Version zu nutzen. Auch nutze ich gerne Visual Studio Code für die Entwicklung. Und beide Tools habe ich über die offiziellen Linux-Repositories von Microsoft in mein System eingebunden. Warum ich das so tat? Weil ich so immer die neuesten Updates bekomme.

Ich war der Meinung, dass mich mein Linux auf angemessene Weise vor Missbrauch durch externe Repository-Maintainer schützt. Das ist aber nicht so!

Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!

Hinweis: Ich habe mir beim formulieren dieses Artikels von Le Chat helfen lassen. Die Erkenntnisse und der gesamte Text wurden aber von mir überarbeitet und geprüft.

Das Problem

Linux gilt als sicher – doch diese Sicherheit hat einen blinden Fleck: externe Repositories. Sobald du ein Repository eines Drittanbieters (z. B. für Microsoft Edge, Visual Studio Code, NVIDIA-Treiber oder Codecs) einbindest, gibst du de facto Administratorrechte an den Repository-Maintainer ab. Warum? Weil dieser beim nächsten Update folgende Dinge tun könnte:

1. Systemkomponenten überschreiben
   Ein Repository kann beliebige Pakete anbieten – auch solche, die Systembibliotheken oder Kernel-Module ersetzen.
   
   Beispiel:
   Ein bösartiges Repository könnte eine manipulierte Version von glibc, openssl oder sogar dem Kernel anbieten.
   
   Folge:
   Dein System wird kompromittiert, sobald du zypper up oder apt upgrade ausführst.
   
   Du fragst wie? Der Maintainer veröffentlicht ein Update für ein scheinbar harmloses Paket (z. B. codecs), das Abhängigkeiten zu Systempaketen hat. Dein apt upgrade (oder zypper up in OpenSUSE) schlägt vor, diese Abhängigkeiten zu installieren. Du sagst wie immer "ja" – und schon ist dein System infiziert.
   
   
2. Automatische Updates als Einfallstor
   Viele Nutzer aktivieren automatische Updates – was praktisch ist, aber gefährlich, wenn externe Repositories eingebunden sind.
   
   Szenario:
   1. Du bindest ein Repository für eine tolle externe Software ein.
   2. Der Repository-Maintainer oder ein Angreifer, der das Repository kompromittiert, veröffentlicht ein bösartiges Update für libc6.
   3. Dein System installiert es automatisch, ohne dass du es merkst.
      
      
3. Social Engineering: Vertrauensmissbrauch
   Repository-Maintainer können Pakete mit vertrauenswürdigen Namen anbieten (zB "openssl-security-patch"), die in Wahrheit Backdoors, Trojaner, Viren oder Spyware enthalten.
   
   Beispiel:
   Ein Repository bietet ein Paket namens "nvidia-driver-fix" an, das tatsächlich einen Rootkit installiert.
   Da der Name seriös klingt, installieren Nutzer es ohne Misstrauen.
   
   

Warum ist das ein strukturelles Problem?

Linux vertraut dem Nutzer. Paketmanager wie zypper, apt oder dnf gehen davon aus, dass der Nutzer weiß, was er tut. In der Realität wählen die meisten Nutzer aber einfach "Installieren", ohne die Quelle zu prüfen. Geschweige denn, dass jemand wüsste wie man eine Quelle prüft…

Es gibt auch keine Standard-Warnungen. Auch wenn diese in der Wirkung zweifelhaft sind; im Gegensatz zu Windows un MacOS warnt Linux nicht aktiv vor den Risiken externer Repositories.

Auch erzwingen manche Hersteller externe Repositories, wenn man immer aktuell sein möchte. Viele Programme (zB Microsoft Edge, NVIDIA-Treiber, Steam, Visual Studio Code) sind nur über externe Repositories verfügbar – Nutzer müssen sie einbinden oder mit Nachteilen leben (siehe später weiter unten).

"Linux ist nur so sicher wie die Repositories, denen du vertraust.
Sobald du ein externes Repository einbindest, öffnest du die Tür
für potenzielle Angriffe durch diesen Anbieter – und
die meisten Nutzer wissen das nicht."

 

Lösungsansätze

Es gibt mehrere Wege, das Problem zu entschärfen – aber keine perfekte Lösung. Hier sind die wichtigsten Ansätze mit ihren Vor- und Nachteilen:

Flatpak: Sandboxing für Anwendungen

Wie es funktioniert:

Anwendungen laufen in einer isolierten Umgebung (Sandbox) und haben keinen Zugriff auf das System (außer auf explizit von Dir freigegebene Bereiche). Pakete kommen aus zentralen Stores (z. B. Flathub), die Signaturen und Reviews erzwingen.

Vorteile:

• Hohe Sicherheit (keine Systemänderungen).
• Automatische Updates (über den Store).
• Keine externen Repositories nötig.

Nachteile:

• Nicht alle Programme verfügbar (zB VS Code, Edge nur als Community-Versionen).
• Langsamer Start (durch Sandboxing).
• Ressourcenintensiv (jede App läuft in einem Container).

Für wen?

Nutzer, die Sicherheit über Komfort stellen und auf offizielle Flatpaks setzen können. Aber Du musst darauf verztrauen, dass der Abbieter des Flatpaks dir nichts böses möchte und dass Du auch regelmässig wichtige Sicherheits-Updates bekommst. bei Community-Versionen sind zumindest Updates nicht selten nie oder nur sehr spät verfügbar.

AppImage: Portable Anwendungen ohne Installation

Wie es funktioniert:

Anwendungen werden als einzelne ausführbare Datei heruntergeladen und ohne Installation gestartet. Keine Repository-Einbindung nötig.

Vorteile:

• Keine Systemänderungen (läuft im User-Space).
• Keine Abhängigkeiten oder Repos nötig.
• Einfach zu nutzen (herunterladen, ausführbar machen, starten).

Nachteile:

• Keine automatischen Updates (Nutzer muss manuell neue Versionen herunterladen).
• Keine Sandbox (AppImages können beliebigen Code ausführen).
• Nicht alle Programme verfügbar (z. B. Treiber, Systemtools).

Für wen?

Nutzer, die keine Repositories einbinden wollen und manuelle Updates in Kauf nehmen.

Manuelle Installation von .rpm/.deb-Paketen

Wie es funktioniert:

Statt ein Repository einzubinden, lädst du die offiziellen Pakete (zB .rpm von Microsoft) manuell herunter und installierst sie. Zum Beispiel so:

sudo dpkg -i /pfad/zur/datei.deb # Debian/Ubuntu
sudo zypper in /pfad/zur/datei.rpm # openSUSE

Vorteile:

• Keine externen Repositories nötig.
• Offizielle Quelle → vertrauenswürdig.
• Volle Kontrolle über installierte Pakete.

Nachteile:

• Keine automatischen Updates (muss manuell geprüft und gemacht werden).
• Umständlich (Nutzer muss selbst auf neue Versionen achten).

Für wen?

Nutzer, die maximale Kontrolle wollen und keine externen Repositories einbinden möchten.

Immutable OS: Unveränderliche Systeme

Wie es funktioniert:

Das gesamte Linux-System ist unveränderlich (Solche Linux-Distributionen sind zB Fedora Silverblue, openSUSE MicroOS). Änderungen werden nur über atomare Updates eingespielt (keine klassischen apt, dnf oder zypper Installations-Befehle). Anwendungen werden als Flatpaks oder Container installiert.

Vorteile:

• Maximale Sicherheit (keine externen Repositories nötig).
• Atomare Updates (keine "kaputten" Systeme nach Updates).
• Isolation (Anwendungen laufen in Containern).

Nachteile:

• Radikale Umstellung (kein klassisches Paketmanagement mehr).
• Nicht alle Programme verfügbar (z. B. proprietäre Treiber).
• Komplex für Einsteiger.

Für wen?

Sicherheitsbewusste Nutzer, die bereit sind, neue Workflows zu lernen.

Distrobox/Toolbx: Containerisierte Distributionen

Wie es funktioniert:

Du erstellst einen Container mit einer vollständigen Distribution (z. B. Ubuntu, Arch) und installierst dort die Software. Die Anwendungen werden im Host-System integriert, laufen aber isoliert im Container.

Vorteile:

• Volle Isolation (externe Repositories bleiben im Container).
• Keine Änderungen am Host-System.
• Volle Kompatibilität (alle Pakete verfügbar).

Nachteile:

• Komplex einzurichten (X11-Weiterleitung, Berechtigungen).
• Ressourcenintensiv (jeder Container ist eine Mini-Distribution).

Für wen?

Fortgeschrittene Nutzer, die externe Software sicher testen wollen.

SIGStore & Cosign: Signaturprüfung für Pakete

Wie es funktioniert:

SIGStore ermöglicht kryptografische Signaturprüfung für Software-Artefakte (inkl. RPM/DEB-Pakete). Cosign prüft Signaturen vor der Installation.

Vorteile:

• Zukunftssicher (wird von der Linux Foundation gepusht).
• Automatisierte Signaturprüfung.

Nachteile:

• Noch nicht flächendeckend eingesetzt.
• Nutzt nichts, wenn Nutzer Signaturen ignorieren.

Für wen?

Zukunftsorientierte Nutzer, die auf neue Sicherheitsstandards setzen wollen.

Die harte Wahrheit ist:
"Es gibt keine perfekte Lösung. Du musst Kompromisse eingehen – entweder
bei der Sicherheit, beim Komfort oder beim Aufwand."

Zusammenfassung: Was kannst du heute tun?

Wenn ein externes Repository für Dich jetzt nicht mehr in Frage kommt, hast Du diese Optionen:

• Flatpak/Snap nutzen, wo möglich (z. B. TeamViewer, Spotify).
• Offizielle .rpm/.deb-Pakete manuell installieren (z. B. VS Code, Edge).
• Externe Repositories strikt beschränken (nur bestimmte Pakete erlauben).
• Immutable OS testen (z. B. Fedora Silverblue), falls du experimentierfreudig bist.
• Distrobox für unsichere Software nutzen (z. B. AnyDesk in einem Container).

 

Die bittere Wahrheit

Linux ist nicht unsicher – aber es erfordert Wissen und Disziplin. Sobald du externe Repositories einbindest, gibst du Sicherheit für Komfort auf. Es gibt aktuell keine Lösung, die beides vereint: Maximale Sicherheit und automatische Updates ohne manuellen Aufwand.

Natürlich gibt es die Vision der optimalen Lösung. Vor allem, wenn Linux jetzt durch mehr Leute genutzt wird, weil Microsoft sich ja größte Mühe gibt den Leuten Windows auszutreiben. Also, was wäre die ideale Lösung?

Vielleicht eine Kombination aus:

• Strikten Sandboxing-Standards (wie Flatpak) für alle Anwendungen.
• Signaturprüfung per Default (wie SIGStore) für alle Pakete.
• Bessere Nutzeraufklärung (Warnungen bei externen Repositories).
• Hersteller-Unterstützung für sichere Distribution (z. B. offizielle Flatpaks von Microsoft, NVIDIA etc.).

Bis dahin bleibt es dabei:

• Entweder du verzichtest auf automatische Updates (manuelle .rpm-Installation).
• Oder du akzeptierst ein Sicherheitsrisiko (externe Repositories).
• Oder du gehst den häufig unbequemen Weg (Flatpak, Immutable OS, Container).