Bis es kracht: Praktische PPAs und ihre Gefahren

Jeder Ubuntu-Nutzer, der sich etwas mit seinem System beschäftigt, kennt sie und setzt sie wahrscheinlich auch ein: Personal Package Archives, PPAs. PPAs werden von Canonical gehostet und machen es für Entwickler einfacher, ihre Software für Ubuntu an den Nutzer zu bringen. Aber zuerst kurz: Was sind PPAs überhaupt?

PPAs sind …

… Paketquellen, die eines oder mehrere Programmpakete bereitstellen. Standardmäßig sind in Ubuntu mehrere Paketquellen aktiv.

Diese sorgen dafür, dass Programme über die Paketverwaltung ganz einfach installiert und aktualisiert werden können. Diese Paketquellen werden von Canonical gepflegt und überprüft. Sie sind insofern sicher, als dass keine Pakete von irgendwelchen Dritten einfach so auf den Rechner des Nutzers kommen können.

PPAs sind nun wie gesagt ebenfalls Paketquellen. Diese werden allerdings nicht von Canonical, sondern von externen Entwicklern befüllt und auf dem aktuellen Stand gehalten. Wird ein PPA dem System hinzugefügt, verhält sich diese Paketquelle wie alle anderen Paketquellen auch. Sie stellt Programmpakete bereit. Aktualisierungen und Installationen von Paketen oder Programmen können nun über die Paketverwaltung verwaltet werden.

Vorteile von PPAs

PPAs haben gegenüber einfachen DEB-Paketen den Vorteil, dass eventuelle Updates ganz einfach über die integrierte Aktualisierungsverwaltung installiert werden – wie bei allen anderen Programmpaketen auch. Im Gegensatz dazu werden DEB-Pakete einmal installiert und bleiben dann auch so, wie sie installiert wurden. Updates können nicht automatisch installiert werden. Der Nutzer muss das dann eventuell manuell machen.

Gefahren von PPAs

Meiner Meinung nach wird heute teilweise zu sorglos mit PPAs umgegangen. Ist ein PPA erstmal eingebunden, bekommt ein Nutzer davon nur noch kaum was mit; das ist das Problem. Ein konkretes Beispiel für die Gefahr könnte etwa so aussehen:

Bindet der Nutzer ein PPA des Entwicklers Florian Unterhupfinger ein, gestattet er diesem Entwickler praktisch bei jeder Aktualisierung oder Installation über die Paketverwaltung den root-Zugriff auf das System. Möglicherweise bekommt der Nutzer davon selbst gar nichts mit. Solange der Entwickler immer fleißig aktuelle Pakete seines Programms baut und alles normal läuft, ist dies auch gar kein Problem.

Was passiert aber, wenn …

• … Florian Unterhupfinger mutwillig oder aus Versehen „böse Software“, wie Viren oder trojanische Pferde ins PPA stellt?
• … Florian Unterhupfinger mutwillig oder aus Versehen kaputte Software für wichtige Systempakete anbietet, woraufhin das System unbenutzbar wird? Man muss immer beachten, dass es für den Entwickler möglich ist, nicht nur wie normalerweise das Programmpaket zu aktualisieren, sondern auch alle anderen Pakete des Systems upzudaten.
• … jemand anderes zu den Zugangsdaten von Florian Unterhupfinger kommt und von da an volle Gewalt über den Inhalt des PPAs hat?

Risiken minimieren

Natürlich sind die Beispiele da oben ein Worst Case-Szenario, denkbar wäre so etwas aber allemal. Was kann man also machen, um solche Risiken zu minimieren?

1. Je weniger PPAs, desto besser: Nicht nur aus Gründen der Sicherheit ist es besser, nicht für jedes billige Tool ein PPA zu installieren. Auch aus Gründen der Systemstabilität ist es besser, bei den von Canonical und Debian-Mitgliedern-gepflegten Paketen zu bleiben.
2. PPAs nur von vertrauenswürdigen Quellen verwenden. Bindet PPAs nur dann ein, wenn die Quelle dieser vertrauenswürdig ist. Wird ein PPA von offiziellen Wine- oder LibreOffice-Mitarbeitern angeboten: Gut. Bei Paketquellen von irgendwelchen Hacker-Seiten würde ich dagegen aufpassen ;-).
3. Je mehr Menschen ein PPA benutzen, desto schneller können Probleme erkannt werden. Wird ein PPA von Tausenden von Menschen eingesetzt ist es sehr wahrscheinlich, dass ein Problem oder eine Unregelmäßigkeit der Paketquelle schnell genug von jemandem erkannt werden kann, bevor man selbst ein Problem damit bekommt. PPAs, die nur von einzelnen Personen verwendet wird, würde ich dagegen besser meiden.

[Bilderquelle]