Wie installiert man Software auf seiner Linux-Distribution? Ganz einfach: Man startet das jeweilige Paketverwaltungstool oder eine darauf aufbauende GUI und installiert Softwarepakete, die eigens vom entsprechenden Distributor bereitgestellt wurden. Bei diesen Paketen kann man faktisch immer sicher sein, dass sie gut auf der jeweiligen Platform laufen, mit dem Rest des Systems zusammenarbeiten und absolut keine Schadsoftware enthalten.
Aber was tut man, wenn man die allerneueste Version X der Anwendung Y installieren will, die nicht in den Archiven anthalten ist? Oder was wenn man ein z.B. ein proprietäres Linux-Spiel installieren will oder eine Anwendung die – warum auch immer – nicht in den Distributionsquellen enthalten ist? Ubuntu-Nutzer suchen in diesem Fall auf Launchpad nach sogenannten “PPAs” (Personal Package Archives), welche öffentliche Softwarequellen darstellen, die zur Liste der Distributionsquellen hinzugefügt werden. Diese PPAs enthalten dann die benötigte Software.
Dieses Vorgehen hat einige tolle Vorteile:
- PPAs sind einfach zu installieren
- PPA-Updates können über den bekannten, generellen Update-Manager eingespielt werden
- Die Integration mit anderen Teilen der Distributions-Infrastruktur ist hervorragend.
Trotzdem gibt es einige Nachteile dieses Konzept, welche PPAs meiner Meinung nach ungeeignet für die Verteilung der meisten Software machen.Dabei muss man natürlich berücksichtigen, dass PPAs als persönliche Paketarchive gestartet sind, nun aber de-facto öffentliche Archive geworden sind.
- Sicherheit: Wenn ein PPA-Paket Schadsoftware enthält, so kann es das gesamte System kompromittieren. Es gibt für Distributionspakete im Grunde keine Grenze für Veränderungen am System.
- Qualität: Software zu paketieren ist nie einfach nur den Upstream-Tarball nehmen und ihn in ein DEB-Paket packen. Bei jeder Distribution gibt es eine Menge Qualitätsstandards einzuhalten sowie diverse weitere Bedingungen, die ein Paket erfüllen muss. Diese Standards und Richtlinien existieren nicht ohne Grund, durch sie wird die Distribution stabil und möglichst Fehlerfrei gehalten, zudem sind sie für eine reibungslose Zusammenarbeit der Pakete nötig. Bei PPAs kann man nie sicher sein, ob alle Richtlinien beim Paketbau eingehalten wurden. So kann man sehr einfach ein “schlechtes” Paket installieren, welches später eventuell Probleme bereitet.
- Upgrades: Wenn man neue Versionen eines Paketes über ein PPA installiert, wird die alte Version des Distributors ersetzt und neue Dateien werden in das System eingebracht, was später bei einem Distributionsupgrade zu probleme führen kann. Auch bei der Installation völlig neuer Pakete existiert dieses Problem. Martin Gräßlin hat das sehr schön an einem Beispiel in seinem Blog beschrieben.
- Ubuntu-Zentriert: PPAs sind nur für Ubuntu verfügbar. Es gibt z.B. keine Fedora-PPAs und nichtmal Debian wird unterstützt. (Momentan wird im Debian-Projekt über ein eigenes PPA-System nachgedacht) Eine distributionsübergreifende Lösung wäre natürlich besser.
Unter Anderem aus diesem Grund entwickle ich Listaller, ein distributionsübergreifendes Programm und Drittanbietersoftware (3rd-party Software) zu installieren. Aber auch bei diesem ist die Installation von 3rd-party Software risikoreich. So kann man z.B. einfach einen neuen Mediaplayer installieren, aber dieser “Mediaplayer” könnte gleichzeitig Malware mitliefern, welche das System beschädigt oder aber persönliche Daten stielt.
Wie kann man also dieses Risiko verhindern? Wie bekommt man 3rd-party Software-Installationen, welche sich an die Distributions-Standards halten, sicher und einfach zu nutzen sind?
Appe hat dafür eine sehr einfache Lösung gefunden: Auf dem iPhone kann über den Apple AppStore ausschließlich von Apple authorisierte Software installiert werden. Damit ist das Risiko, Schadsoftware zu installieren bei fast null.
Dieser Ansatz ist aber keine wirkliche Lösung für das eigentliche Problem, und in der Linux/FLOSS-Welt auch völlig unsinnig. Sobald man aber die Möglichkeit hat, nicht geprüfte Software zu installieren, kann man auch sehr einfach Mist auf dem System installieren. (Man muss sich da nur einige Windows-Desktops anschauen… :P) Also müssen Nutzer vor der Installation selber drüber nachdenken, wass sie eigentlich tun um dann zu entscheiden, ob sie die Software installieren wollen.
Okay, also wie bringt man Nutzer dazu, über dieses Problem nachzudenken? Mozilla hat zu diesem Zweck eine Wartezeit von 6 Sekunden vor der Installation eines Firefox-AddOns eingeführt:
Das Warndreieck erinnert die Nutzer daran, nie Software zu installieren, der sie nicht vertrauen. Die Wartezeit soll die Anwender dazu bringen, den entsprechenden Text über den Buttons zu lesen.
Theretisch funktioniert das, aber in der Praxis finden wohl die meisten User die Wartezeit einfach nur lästig und machen andere Dinge während sie warten, oder zählen lieber die Sekunden runter anstatt den Text zu lesen.
Außerdem können Nutzer nicht entscheiden, ob sie diesem AddOn trauen sollen. Woher sollen sie das wissen? Wenn man Malware verteilen will, schreibt man das ja nicht einfach in den Softwaretitel und man gibt sich große Mühe, unauffällig zu wirken.
Zudem wollen die meisten Nutzer die Software wohl einfach nur “haben” und sich nicht noch großartig um Sicherheitsaspekte kümmern.
Windows behandelt dieses Problem anders:Sie prüfen die Signatur einer aus dem Internet geladenen ausführbaren Datei und zeigen einen Dialog an, welcher ein paar Informationen über die Anwendung sowie die Warnung “Dieser Dateityp könnte ihren Computer beschädigen” anzeigt. – Das ist auch keine wirklich hilfreiche Information für viele Leute – sie wissen das bereits. Und Signaturen kann im Grunde jeder erstellen.
Wie wär’s also mit ein wenig mehr technischen Informationen?
“Widget will be installed into /Applications” – sehr schön! Aber in diesem Fall werden viele Nutzer nicht wissen, wie sie selbst so einfache Informationen wie das Installations-Ziel interpretieren sollen und ob das nun gefährlich ist.
Wie also kann man nun Nutzer davor schützen, schädliche Software zu installieren, welche das System beschädigt oder ihre persönlichen Daten über das Internet an unauthorisierte Dritte versendet? Die Antwort ist sehr einfach: Das kann man nicht und man wird es niemals können. (Es sei denn, man baut eine Apple-ähnliche Lösung auf) Die Möglichkeit, Schadsoftware zu installieren gehört nunmal kurioserweise auch zu der Freiheit, beliebige Software installieren zu können.
Allerdings lässt sich das Risiko der Malware-Installation vermindern. Die Beispiele zeigen, dass viele bunte Warn- und Infodialoge für den Nutzer nicht hilfreich sind und ihn nur in wenigen Fällen zum Nachdenken über ihre nächsten Klicks bringen.
Ich schlage also vor, diese Art von Dialog vor Installationen nicht mehr anzuzeigen. Stattdessen sollen Tools wie eben z.B. der Listaller nicht vertrauenswürdige Pakete erstmal automatisch zurückweisen. Nicht vertrauenswürdig meint in diesem Fall, dass technisch erkennbar ist, dass die Pakete nicht vertrauenswürdig sind, wenn z.B. sie nicht GPG-Signiert sind oder der entsprechende Schlüssel zurückgerufen wurde.
Nutzer müssten die Konfiguration des Listallers abändern um derartige Software zu installieren. Wenn ein Nutzer diesen Aufwand betreibt, will er die Software wirklich haben und hat auch über die Folgen nachgedacht.
Auch das anzeigen nützlicher Dialoge über den GPG-Schlüssel kann in vielen Fällen hilfreich sein.
Als Beispiel dient hier ein Dialog des ZeroInstall Softwareverteilungssystems:
Der Dialog zeigt sehr schön, warum Nutzer Paketen, welche mit diesem Schlüssel signiert sind, trauen sollen, also können Nutzer hier begründet entscheiden, ob sie das Paket installieren wollen. (Z.B. “Key belongs to a Debian maintainer” zeigt an, dass eine Person mit wirklich tiefergehendem Wissen über Linux dieses Paket gebaut hat.)
Es gibt auch einige andere Wege, die Gefahr, das System mittels 3rd-party Software zu kompromittieren, zu minimieren: Um eine Installation mit den entsprechenden Regeln der jeweiligen Distribution ablaufen zu lassen und die Gefahr von “schlechten” Paketen zu verringern, sollte das Installationsprogramm die volle Kontrolle über die Installation haben und nicht die Person, die das Paket erstellt hat. Distributoren müssen dann nur noch das Installationsprogramm anpassen um jede 3rd-party-installation mit ihren Richtlinien kompatibel zu machen.
Auch “gefährliche” Funktionen wie benutzerdefinierte Scripte während einer Installation sollten mit dieser Art von Paket nicht möglich sein. Die Anwendungen, die so installiert wurden sollten zudem zunächst einmal in einer Sandbox laufen.
Verglichen mit einem PPA, wo Pakete so ziemlich alles machen können wäre die Listaller-Lösung oder eine ähnliche Lösung der bessere Ansatz für die meisten Anwendungen. Wenn ein Programm wirklich die volle, absolute Kontrolle über sein Setup braucht (was nach meiner Meinung nur eine Systemanwendung, ein Daemon oder eine Bibliothek sein kann), erst dann sollte zu einem PPA gegriffen werden. Solche Anwendungen benötigen wahrscheinlich sowieso ein paar speziellere Anpassungen an die Distribution.
So sehr ich auch gegen das GNOME-Prinzip der “Nutzerbevormundung” in deren Arbeitsabläufen bin (wenig Einstellungen, etc.) im Fall von 3rd-party Installationen scheint das wirklich der einzige Weg zu sein um sie zumindest ein wenig sicherer zu machen.
Info: Dieser Artikel ist derzeit nur eine lose Gedankensammlung, aber trotzdem denke ich dass einige Funktionen, die in diese Richtung gehen, innerhalb der nächsten Tage im Listaller implementiert werden. 🙂
Ich habe letztens etwas über eine Art Dateisystem Layer gelesen. Damit kann man eine Art Layer über ein Dateisystem lege, wobei sämtliche änderungen in einer Datei statt auf der Festplatte direkt gespeichert werden. Eigentlich könnte man soetwas für jeden Benutzer anbieten. Alle Installationen, die nicht über ein Distributor Paketsystem laufen, werden nur auf diesem Layer installiert. Die Userdaten sind dann zwar noch nicht in Sicherheit, aber das System hat selbst einen gewissen Schutz.
Ein Sicherheitssystem wie es Android mitbringt fände ich auch nicht schlecht. Jedoch sollte man da speziell die Userdaten Zugriffe freigeben müssen.
> Appe hat dafür eine sehr einfache Lösung gefunden: Auf dem iPhone kann über den Apple AppStore ausschließlich von Apple authorisierte Software installiert werden. Damit ist das Risiko, Schadsoftware zu installieren bei fast null.
> […]
> Die Antwort ist sehr einfach: Das kann man nicht und man wird es niemals können. (Es sei denn, man baut eine Apple-ähnliche Lösung auf)
Oder auch nicht, es ist ja nicht so, dass keine Malware für iPhones über den AppStore in Umlauf gebracht wurde. Das mag weniger sein und weniger offensichtlich eingebaut sein, als bei Systemen ohne Kontrolle, davon auszugehen, dass Apps über ein solches System automatisch frei von Malware sind, ist falsch. Siehe dazu auch http://news.cnet.com/8301-27080_3-10446402-245.html
Worauf ich eigentlich hinaus will, ich glaube nicht, dass es derzeit und wohl auch in Zukunft irgendein System gibt, dass es dem Nutzer erlaubt einfach gedankenlos Software zu installieren. Auch ein Review-Verfahren von Software schafft das nicht, egal ob das offen oder geschlossen ist.
Was ich noch vergessen habe:
Unter Ubuntu stört mich schon sehr, das es keine Abgrenzung zwischen verschiedener Software gibt. Spiele, Bürosoftware sollte beim Installieren und auch Updaten keine gleichwertige Stellung wie Grub, KDE/Gnome oder xServer haben.
Ich würde gerne bestimmten von mir administrierten PC’s und User die Möglichkeit einräumen beliebig Spiele und Gadgets zu installieren.
@Tomboy: Mich stört diese ebenfalls schon sehr lange. Ich bin der Meinung dass drittsoftware und die aus den PPAs in jedemfall mit anderen Rechnern installiert und ausgeführt werden sollten. So dass ein Solches Programm zwar ausgeführt werden kann und in seinem Bereich Daten schreiben kann, aber keinen Schreibzugriff auf die Systemdateien (und auch die Userdaten) haben darf.
Ich denke Linux bringt dafür von hause schon die Infrastruktur mit, man müsste sie nur besser nutzen.
hallo
ich habe deinen Beitrag mit Interesse gelesen, und bin auf folgende Idee gekommen.
“wine”
wieso wine, fragt Ihr euch jetzt sicher.
Mit Wine ist es möglich, Windows Programme unter Linux zu installieren (im Prinzip auch Schadsoftware). Dabei werden die Windows Programme im Home-Verzeichnis installiert, und berühren das eigendliche System nicht.
Vorteil
Installiert man Schadsoftware per Wine, wird im schlimmsten Fall der Benutzer unbrauchbar,
Das System selber ist damit nicht gefärdet.
Nachteil
bei einem mehrbenutzer System, muss die Software für jeden Benutzer neu installiert werden.
gruss
tuxsuisse
Der Listaller macht genau das per default. Sofern möglich hat der Nutzer aber noch immer die Möglichkeit, die Software für alle Nutzer zu installieren.
Momentan hat das Projekt noch eher den Status einer Techdemo, aber sobald es was zu sehen gibt, werde ich die Architektur noch mal ausführlich erläutern 🙂
“Installiert man Schadsoftware per Wine, wird im schlimmsten Fall der Benutzer unbrauchbar,
Das System selber ist damit nicht gefährdet.”
Ich denke, dass das nur einen Teil des Problems löst. Denn selbst User dürfen i.Allg. auf die Daten der anderen User lesend zugreifen. Mit einer User-Installation ist zwar nicht System gefährdet, aber die eigenen Daten und die Daten der weiteren User durchaus. Daher sollten per Standard-Installation die Home-Verzeichnisse auch vor Lesezugriff geschützt werden und nur explizit vom User freigegeben werden. Zum Datenaustausch zwischen den Usern könnte ein “shared”-Verzeichnis angelegt werden, in welchem alle User lesenden Zugriff auf die Daten der anderen haben (ähnlich wie bei MS Windows).
Es sollte (möglichst) kein Schädling auf ein System gelangen können. Es könnte durchaus möglich sein PPAs, oder ähnliche 3rd-Party-Software-Repositories, sicherer zu gestalten.
Ein Problem stellt, die relative Anonymität des Autors und Repository-Anbieters dar. Durch Anonymität ist ein Anbieter verseuchter Software nicht, oder schwer real identifizierbar. Es müsste also eine Technik geschaffen werden, die Autoren im Falle eines Vergehens identifizierbar macht ohne den allgemein Schutz der Anonymität zu untergraben.
Ein mögliches Szenario zur Sicherung der Identität eines PPA-Anbieters (also der Inhaltsanbieter – i.Allg. ein Programmierer) könnte das zusenden eines “Freischaltcodes” über einen eindeutigen Zustellungsweg. Dies könnte zum einen durch ein Anschreiben per Brief oder mittels eines Identität sichernden E-Mail-Anbieters wie E-Post-Brief oder De-Mail (von den Fehlentwicklungen dieser Dienste einmal abgesehen). Briefe sind aufgrund der hohen Kosten kaum realistisch. Bei Verwendung einer der genannten E-Mail-Anbieter müsste der PPA-Provider neben der E-Mail-Adresse keine weiteren persönlichen Daten erfassen. Im falle einer nötigen Verfolgung kann die Person über die eindeutige E-Mailadresse ermittelt werden. Natürlich sind auch diese Mechanismen mit ausreichend krimineller Energie umgehbar, stellen jedoch bereits Hürden dar, die nicht jeder auf einfache Weise umgehen könnte. De-Mail und E-Post-Brief sind zudem nationale Insellösungen – ein internationales System wäre nötig.
Wichtig wäre, PPA-Anbieter nicht unnötig zu gängeln. Unnötige Daten sollten nicht erfasst werden, erfasste Daten nicht verbreitet oder veröffentlicht werden und auf Wunsch wieder gelöscht werden.
Persönlich identifizierbare PPAs sollten gegenüber dem anwenden User als solche kenntlich gemacht werden – mit Stichwort (evtl. “Vertrauenswürdig”) und Hinweistext, was erfasst wurde. Weiterhin sollten die relativ Anonymen PPAs weiterhin möglich sein, denn oftmals sind PPAs nicht für den Endnutzer, sondern zB. für einen Entwicklerkreis. Auch hier sollte beim Installieren darauf hingewiesen werden – mit Stichwort (evtl. “Anonymes PPA”) mit Hinweistext über das Risiko. Unsignierte PPAs sollten ebenfalls ausgewiesen werden – mit Stichwort (evtl. “Nicht Vertrauenswürdig”) und Hinweistext über Risiko und Hintergrund (wird ja schon gemacht).
Im Falle der Verbreitung von Malware durch ein identifizierbares PPA sollte eine staatliche Ermittlung erst nach interner Prüfung durch den PPA-Hoster eingeleitet werden. Fehler können immer auftreten und der PPA-Anbieter könnte zu unrecht beschuldigt werden. Ein PPA-Anbieter könnte auch Software, die nicht aus seiner Hand ist verbreiten – zB. die neueste Version einer Software. Man sollte also immer von der Unschuld eines identifizierbaren PPA-Anbieters ausgehen. Dies ist schon allein wichtig, damit man sich diesen Mechanismen überhaupt anvertrauen kann.
Es sind verschiedene Vorgehensweisen durch den PPA-Hoster möglich. Zum ersten kann i.Allg. der Quellcode überprüft werden. Bösartige Funktionen sollten aufspürbar sein. Bösartiges Verhalten ist i.Allg. ebenfalls bei CSS identifizierbar. Das PPA kann weiterhin beobachtet werden, zB. wer, wie häufig darauf zugreift und was gemacht wird. Dies könnte für evtl. folgende Ermittlungen dienlich sein. Das PPA kann zudem abgeschaltet werden – User informiert werden. Durch die eindeutige Identifizierung können staatliche Ermittlungen eingeleitet werden.
Die Sicherung des PPAs besteht also darin, dass sich ein PPA-Anbieter identifizierbar macht. Dabei sollte immer von der Ehrlichkeit ausgegangen werden. Persönliche Daten sollten so gering wie möglich gehalten werden. Persönlicher Schutz für den PPA-Anbieter entsteht durch die Trennung der Persönlichen Daten (beim staatlichen E-Mail-Anbieter) und dem PPA-Account.
Es ist davon auszugehen, dass Menschen oder Gruppen mit starker krimineller Energie auch solche (oder bessere) Mechanismen umgehen können. Doch würden sie bereits einen erheblichen Schutz im Vergleich zum jetzigen System darstellen – ganz zu schweigen im Vergleich zur Installation von Binärpaketen von “unbekannten” Webseiten.
Ob das ein wirklich guter und realistischer Mechanismus ist, weiß ich nicht. Zumal das Problem mit der Insellösungen des E-Post-Briefs oder De-Mail besteht. War nur ein Gedanke zum Thema.
Schöne Grüße.
Entschuldigung für die massigen Rechtschreibungs-, Komma-, Aufzählungs-, Grammatikfehler sowie Wortauslassungen! Hab beim Schreiben zu viel geändert und nicht mehr Korrektur gelesen. Hoffe der Inhalt ist trotzdem verständlich.
Anmerkung:
Natürlich meine ich im ersten Absatz, dass die Anwenderdaten per Standard nur für andere Anwender nicht lesbar sein sollten (group und other). Ich glaube das versteht sich von selber, habe es aber nicht eindeutig ausgedrückt.
Grüße.
Sowas ähnliches existiert bereits und wird in der Linux-Welt zur identifizierung genutzt: http://wiki.ubuntuusers.de/GnuPG/Web_of_Trust
Aus dem verlinkten Wiki zum Thema “Web of Trust”:
“Das OpenPGP-System, das auch hinter GnuPG steckt, benutzt einen anderen Ansatz, das Web of Trust (dt: Netz des Vertrauens). Hier sind es keine zentralen Instanzen, die die Signierarbeit übernehmen, sondern jeder Benutzer X kann den Schlüssel eines jeden Benutzers Y signieren und ihm damit Glaubwürdigkeit verleihen, nachdem er sich von dessen Identität überzeugt hat. Natürlich stellt sich die Frage, wie vertrauenswürdig denn nun Benutzer X selber ist. Die Antwort im Web of Trust lautet: Das bestimmt jeder selber. Jeder Benutzer legt in seinem Schlüsselbund fest, ob er seinen Kommunikationspartnern z.B. “komplett” oder “teilweise” vertraut. Wenn man nun einen Schlüssel erhält, über dessen Authentizität man sich nicht sicher ist, so vertraut ihm das GnuPG-System, sofern er von mindestens einem “komplett” oder mehreren “teilweise” vertrauenswürdigen Bekannten signiert wurde.”
Das hört sich ganz gut an. Bin mir aber nicht so sicher, wie gut das System zur weitgehenden Sicherung von PPAs gegen Schadcode geeignet ist.
Ich denke es sollte für einen Malware-Verbreiter kein Problem sein, jemanden (zB. unter Vortäuschung falscher Identitäten) zur Signierung seines Schlüssels zu überreden. Des weiteren könnte eine Gruppe von Angreifern, sich gegenseitig signieren und somit Vertrauenswürdigkeit vortäuschen. Darüber hinaus wird nicht unbedingt die sich hinter einem Schlüssel befindliche reale Person sichergestellt, sondern ein eingetragener Name. Das bedeutet, dass lediglich dem Schlüssel ein gewisses Vertrauen gewährt wird, jedoch im Missbrauchsfall keine Person ermittelt werden könnte.
Allerdings würde das “Web of Trust”-System Missbrauch bereits erschweren. Im Falle eines Missbrauches könnte zumindest einem Schlüssel das Vertrauen entzogen werden und ein neuer, als vertrauenswürdig eingestufter Schlüssel wäre nötig um Vertrauenswürdigkeit vorzutäuschen.
Das Problem “Web of Trust” sehe ich also in erster Linie darin, dass es die reale Identität einer Person nicht sichern kann (dazu ist es auch nicht konzipiert). Es basiert auf dem Prinzip des Vertrauens mehrerer Signierender in die Daten und Ehrlichkeit des zu Signierenden. I.Allg. kennt ein User, der ein PPA nutzen möchte, keinen der Signierenden und kann daher deren Authentizität nicht einschätzen. Bei der Installation von Software gibt es, im Gegensatz zu E-Mails, kein “teilweises Vertrauen” (Entweder man installiert es, oder eben nicht). Auch stellt sich die Frage, ab wie vielen bestätigenden Signaturen ein PPA als vertrauenswürdig gelten sollte. Wie erwähnt, könnte sich ein Ring von Angreifern gegenseitig signieren, während ein einfacher Hobbyprogrammierer keine (nennenswerte Menge an) Signaturen vorweisen könnte.
Was ich vorgeschlagen habe ist an das SSL-Zertifizierungsverfahren angelehnt. Eine zentrale, vertrauenswürdige Instanz bestätigt die Identität. Im Gegensatz zur SSL-Zertifizierung entstehen jedoch keine horrenden Kosten für die Überprüfung der persönlichen Daten. Die Sicherung der Identität übernimmt der Staat indem er eine persönliche eindeutige E-Mail-Adresse vergibt. Dabei reicht es, wenn die Identität hinterlegt ist, eine Weitergabe der persönlichen Daten an den PPA-Hoster oder eine Veröffentlichung wäre nicht nötig. Anmerkung: Auch hier ist zu hinterfragen, wen erreicht die Mail wirklich, wer hat Zugriff, ist das System im größeren Maßstab angreifbar, mit welchen Konsequenzen hat der Inhaber einer missbrauchten Mailadresse zu rechnen?
Natürlich könnte auch eine unabhängige Instanz (wie bei SSL) die Identität sicher stellen. Allerdings dürfte dies mit Kosten und relativ hohem Aufwand verbunden sein.
Anmerkungen:
Ich bin kein Freund der De-Mail oder des E-Post-Briefes. Gerade die fehlende End-to-End-Verschlüsselung und die Kosten für einen relativ billigen Service könnten das System unbrauchbar machen.
Eine nicht staatliche, zuverlässige, vertrauenswürdige Zertifizierungsinstanz wäre vorzuziehen. Ein dezentrales System wie “Web of Trust” wäre, wenn es real ausreichend Schutz bietet, einem Zentralen vorzuziehen.
Freundliche Grüße.
Wenn man das ganze hier liest, möchte ich gerne ein paar grundsätzliche fragen über das Paketsystem stellen. Ich kenne mich damit nicht aus, lese aber immer wieder gerne über die neusten Entwicklungen.
– Welche Richtlinien bezüglich Sicherheit hat eigentlich Ubuntu für die Quellen und PPA?
– AppArmor ist doch auch so ein Thema. Ist das Pflicht?
– Soweit ich weiss, hat z.B. Microsoft bestimmte Programmierelemente verboten, gibt es sowas auch bei Linux, also befehle die zumindest als nicht zum guten Ton gehörend und deshalb vielleicht Aufnahme in die Quellen verhindert?
– Wie stellt Canonical eigentlich sicher das die vielen Pakete und Programme viren- und schädlingsfrei sind. Vertraut man da einfach Debian? wie handhabt das Debian?
Da du dich hier wohl gut auskennst, könntest du hierüber einen Artikel schreiben?
Ja, ein Artikel wäre vielleicht ganz gut, da wohl auch ziemlich viel Unsinn über diese Konzepte verbreitet wird.
Ich schraibe was dazu, daher hier nur ganz kurz:
AppArmor ist keine Pflicht und hauptsächlich für Server interessant, unter Linux sind bestimmte Programmelemente ebenfalls verboten oder müssen explizit eingeschaltet werden. Wie das gehandhabt wird hängt aber am jeweiligen Projekt. Sollte dieses jedoch grobe verstöße enthalten, würde z.B. das Paket in Debian durch die QA fallen. Canonical vetraut Debian und den eigenen Entwicklern – das ganze läuft ähnlich wie bei anderen Software-Projekten durch gegenseitige Kontrolle. Das Einschleusen von Schadsoftware ist fast unmöglich.
Der Artikel war sehr interessant. Genau richtig nach einer anstrengenden Arbeitswoche.
Aber irgendwie habe ich das Gefühl, dass hier eine Lösung, die es noch nicht gibt, ein Problem sucht, dass bestenfalls ein Phantom ist. Ich installierte mir in 5 Jahren Linux noch kein einziges mal Malware oder Pakete, die viel Probleme gemacht haben. Gut, das kann sich ändern aber wenn ich mal in die Verlegenheit kommen sollte Software von außerhalb der Distro-Repos zu holen, dann muss ich eh nach der Quelle suchen. Dabei schau ich immer mehr oder weniger automatisch, ob das Paket/das Repo Probleme verursachen würde. Also alles halb so schlimm.
Wie gesagt: Interessant das Thema mal zu beleuchten, aber momentan sucht da eine Lösung noch nach dem Problem.
Es geht darum, bestimmte Möglichkeiten sofort auszuschließen und Probleme zu beheben, bevor sie entstehen.
Wenn man sagt “ist jetzt ja eh noch kein Problem”, dann hat man in ein paar Jahren ein System, bei dem man solche Funktionen nicht mehr einführen kann.
Ich möchte gerne keine Software “broken by design” entwickeln sondern, sofern sinnvoll, auch Dinge implementieren, die für die Zukunft wichtig sind.
Außerdem gehörst du vermutlich eher zu den Nutzern, die wirklich verantwortungsvoll mit ihrem Rechner umgehen 😉
hallo
“Ich installierte mir in 5 Jahren Linux noch kein eivnziges mal Malware oder Pakete, die viel Probleme gemacht haben.”
Was sicherlich auch etwas mit Erfahrung zutun hat, ich hatte vor Linux jahrelang windows, auch da hatte ich keine malware, weil ich ganz einfach nicht auf alles geklickt habe, wo blinkt.
Doch was ist mit Benutzern die ganz einfach drauflos klicken???
Ein einfaches Script, dass das System unbrauchbar macht, ist in 5min geschrieben, und dies auch unter Linux.
Ein solches Script als deb in einem PPA rep. zur Verfügung zu stellen ist auch nicht viel schwerer. Und bei einer PPA hätte man Zugriff auf das ganze System.
Auch schon nur deshalb finde ich PPA’s nicht vertrauenswürdig.
gruss
tuxsuisse
Man sollte Aufhören zu Versuchen nun auch unter Linux die Benutzerrechte Beschneiden zu wollen , sonnst landen wir ganz schnell bei einem “Geschlossenen System”.
Der Nutzer wird es sich gerade unter einen “Open Source” System die Bevormundung nicht Gefallen lassen nur noch “Bestimmte” Software aus “Software Center” auf sein System Installieren zu Dürfen , auch wenn diese Einschränkung gut gemeint ist !
Zumal auch die restriktivsten Installations- Einschränkungen nicht vor Schadsoftware schützen können wenn die Anwendungsprogramme wie zb. der Browser oder Office Programm einen Bug haben.
Es hilft nur ein Ansatz und das ist ein Viren Scanner wie bei einem Windows möchte man die Freie Software Installation Behalten und Ubuntu nicht zum Apple iOS System machen.