Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
12.07.2020, 19:06:47

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
Statistiken
  • Beiträge insgesamt: 670381
  • Themen insgesamt: 54317
  • Heute online: 470
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema:  In welchem Verzeichnis speichert man zusätzliche Software und eigene Scripte ab?  (Gelesen 4949 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

In einem anderen Thread las ich vor einigen Tagen folgende Bemerkung:
Ich halte (quasi) portable Programme aus dem Heimatverzeichnis heraus ausgeführt für eine ganz gefährliche Idee - zurück in der Zeit von Windows 98, wo es keine getrennten Benutzerrechte gab. Der Selbstschutz des Systems, das unkontrollierte Veränderungen an den binären, ausführbaren Dateien verhindert, wird brutal ausgeschaltet. Wenn schon, dann gehören solche Programme nach /opt verschoben, wo der Selbstschutz greift.
Das hat mich jetzt eine Weile beschäftigt, ich verstehe es nämlich nicht.
Ich gebe zu, dass ich immer wieder mal damit konfrontiert bin, dass die Rechteverwaltung bei Linux eine komplizierte Angelegenheit ist und ich gelegentlich Probleme damit habe.

Ich kenne das Verzeichnis /opt/… auch – als möglichen Speicherort für zusätzliche Software wie z.B. Google-Chrome, weil diese dann systemweit zur Verfügung steht. Es gibt auch noch andere denkbare Orte, wie z.B. /usr/… oder /usr/local/… meine ich.

Andererseits habe ich auch des öfteren von der Möglichkeit gelesen, eigene Scripte oder Software in /home/$USER/bin (~/bin) abzulegen, wenn sie nur für den persönlichen Gebrauch bestimmt sind. Dieses Verzeichnis kennt das System und man findet es in der Umgebungsvariable $PATH. Der Vorteil ist eben, dass man dort vorhandene Dateien als User ablegen und ausführen kann und keine Rootrechte benötigt. 

Nun wäre ich sehr dankbar für eine etwas ausführlichere und sachlich begründete Erklärung, warum das ein so großes Risiko darstellen soll.
Denn zu Windows 98 will ich wahrlich nicht zurück.

Welche Rechte oder auch andere Maßnahmen wären denn dann für Dateien in ~/bin zu empfehlen, um das Risiko so gering wie möglich zu halten?
Mal vorausgesetzt, es ist überhaupt eine Option, dort etwas abzulegen.

Ist ein "portabler" Browser riskanter als beispielsweise ein Script für den Conky-Start oder zum Kernel-Aufräumen? 

Oder anders gefragt, welche Kriterien gibt es für die Wahl des Speicherortes?
« Letzte Änderung: 05.11.2017, 05:46:35 von aexe »

Moin,
wenn ich mir das UU-Wiki ansehe scheint /usr/local/ der Richtige Ort für eigens installierte Programm oder Scripte zu sein.
Verzeichnisstruktur auf UU: https://wiki.ubuntuusers.de/Verzeichnisstruktur/
und ein von UU verlinktes Schulungsvideo: https://youtu.be/S-kg37u4tp8?t=18m47s
« Letzte Änderung: 05.11.2017, 12:31:28 von kuehhe1 »

Was ist denn damit:
Zitat
Download an application, make it executable, and run! No need to install. No system libraries or system preferences are altered.
https://appimage.org/   "Linux apps that run anywhere"
 ??

Wer gern auf Nummer sicher geht:
Zitat
Can also run in a sandbox like Firejail.
  8)
« Letzte Änderung: 05.11.2017, 09:45:15 von aexe »

Hallo,

zusätzliche Software, die nicht installiert werden muss, speichere ich bei mir unter /home/ulf/programme.
Dazu gehören zum Beispiel 2 Versionen der Digikam Appimages. (Nicht jedes Update verbessert alles  :D )

Für Digikam liegen dann 2 Starter auf dem Desktop

Grüße Ulf

Interessantes Thema, worüber ich mir in der Vergangenheit anscheinend zu wenig Gedanken gemacht habe. Ich benutze für solche Software bisher das jeweilige Downloadverzeichnis, also auch ein Unterverzeichnis von /home . Abgesehen von der Einfachheit, ist dieses Vorgehen ja anscheinend grottenfalsch.

Mich würde schon auch interessieren, was daran genau so risikobehaftet ist und wie der "Selbstschutz des Systems" hier funktioniert und wie ein Programm aus dem /home des users heraus mit dessen Rechten gestartet für das System doch so gefährlich werden kann. Man liest ja hier im Support immer mal wieder von "verbogenen Rechten", die dann zu Fehlern führen. Scheint ja aber schon ein Sinn dahinter zu stehen.

Das mit den appimages ist schon ne sehr komfortable Sache und auch was Aktualität von Software angeht (grundsätzlich ja auch gut und ein Sicherheitsaspekt) hinken die repos doch oftmals sehr weit hinterher.

ZeckeSZ

  • Gast
Welche Rechte oder auch andere Maßnahmen wären denn dann für Dateien in ~/bin zu empfehlen
Grundsätzlich laufen Skripte und auch AppImages mit den Rechten des Users, der sie aufruft, ob das nun aus /opt oder aus dem Heimatverzeichnis heraus geschieht. Da sehe ich keinen Handlungsbedarf.

Ich vermute, dass Cosmo ein Problem darin sieht, dass die Möglichkeit besteht, die AppImages ohne root-Rechte verändern und manipulieren zu können, wenn sie sich im /home und nicht z.B. in /opt befinden. Aber mal ganz ehrlich: Wäre ich in der Lage, die Programme so umzustricken, dass ich auf diese Art und Weise z.B. an root-Rechte gelangen kann, dann bräuchte ich dazu doch nicht diese Apps. Da gäbe es bestimmt andere Mittel und Wege.

AppImages, wenn ich sie denn tatsächlich einmal nutze, werden bei mir immer in einer Sandbox (Firejail) gestartet. Warum? Erstens kenne ich den Ersteller nicht und kann mir daher nie sicher sein, ob ich mir mir diesem Programm nicht vielleicht irgend eine Malware eingefangen habe. Zweitens besteht ja auch die Möglichkeit, dass die gestarteten Programme Sicherheitslücken enthalten, die mein System gefährden könnten, da es sich noch um uralte Versionen handelt.

Programme wie z.B. youtube-dl speichere ich unter ~/.local/bin, das liegt von Haus aus auch im Pfad. Das Verzeichnis "bin" sichtbar in meinem ~ würde mich stören.
« Letzte Änderung: 05.11.2017, 12:50:55 von ZeckeSZ »

Erstens kenne ich den Ersteller nicht und kann mir daher nie sicher sein, ob ich mir mir diesem Programm nicht vielleicht irgend eine Malware eingefangen habe. Zweitens besteht ja auch die Möglichkeit, dass die gestarteten Programme Sicherheitslücken enthalten, die mein System gefährden könnten, da es sich noch um uralte Versionen handelt.
Das ist sicher richtig, zumal es seit einiger Zeit geradezu einen "App-Boom" gibt.
Andererseits kann man sich ja AppImages auch selbst bauen, dann kennt man den Ersteller. Und wenn das AppImage aus dem gleichen Ursprung wie das entsprechende  *.deb Paket ist, warum sollte dann die Gefahr von Malware eine größere Rolle spielen?
Den Qupzilla-Browser gibt es z.B. in beiden Versionen direkt von der Homepage.

Ich will auch keineswegs den wahllosen Gebrauch von AppImages propagieren, wenn denn der übliche, reguläre Weg der Software-Installation über die Paketverwaltung möglich und sinnvoll ist.
Manchmal möchte man aber vielleicht eine andere Software-Version testen, ohne die bereits vorhandene entfernen zu müssen. In so einem Fall bietet sich eben die "portable" Installation an, die ja auch nicht unbedingt in ~/bin liegen muss. Man kann das Verzeichnis auch anders nennen.

Und nun hat mich das doch etwas erschreckende Gefahren-Szenario von Cosmo zu dieser Anfrage veranlasst, weil man ja immer gern dazulernt und auch die geschätzte Sicherheit von Linux nicht gefährden will. Deswegen würden mich halt konkrete, nachvollziehbare Hintergründe für seine eindringliche und sehr drastische Ablehnung interessieren.
« Letzte Änderung: 05.11.2017, 13:53:18 von aexe »

Appimages:
Ich verwende digikam Appimages aus folgenden Gründen:
- die Images sind aktueller => Appimage digikam 5.8 über Paketverwaltung bekomme ich (LM 18.2) nur digikam 4.*
- die Appimages verändern nichts am System, sie bringen alle Dateien mit.
- oder ich möchte die Software nicht fest im System haben (Chromium)

Gruß Ulf



Ich halte (quasi) portable Programme aus dem Heimatverzeichnis heraus ausgeführt für eine ganz gefährliche Idee - zurück in der Zeit von Windows 98, wo es keine getrennten Benutzerrechte gab. Der Selbstschutz des Systems, das unkontrollierte Veränderungen an den binären, ausführbaren Dateien verhindert, wird brutal ausgeschaltet. Wenn schon, dann gehören solche Programme nach /opt verschoben, wo der Selbstschutz greift.
Äh? Und was hindert mich nun daran, ein Programm aus /opt in mein Home zu kopieren, es zu verändern und auszuführen? Was hindert mich überhaupt daran, ein "fieses Programm" gleich selbst zu schreiben und es auszuführen? Kann es sein, dass Linux das auch gar nicht verhindern muss?

Cosmo

  • Gast
Eines der größten Sicherheitsmankos von Windows 9x und den DOS-Vorläufern bestand darin, daß jeder Angreifer ohne die geringste Einschränkung das System kompromittieren konnte. Der Grund besteht darin, daß ein erfolgreicher Angreifer generell die Rechte auf dem System hat, die der angemeldete Benutzer ebenfalls hat. Bei W9x hieß das: alle Rechte ohne jede Einschränkung.

Nachdem andere das schon länger vorgemacht haben, wurden dann mit Windows NT als echtem Mehrbenutzersystem die Rechtetrennung eingeführt. Folge: Ist der angemeldete Benutzer als Standardbenutzer unterwegs, hat also keine Rechte für administrative Zugriffe und Veränderungen, konnte in der Folge auch ein erfolgreicher Angreifer Systemdateien einschließlich Programmdateien nicht mehr verändern. Da, wo das dennoch möglich ist, handelt es sich um einen der dümmsten Benutzerfehler, der in der Windows-Welt gang und gäbe ist, nämlich das ständige Arbeiten als angemeldeter Administrator, oder um einen dicken Sicherheitsfehler, aka Rechte-Eskalation.

In Linux ist es selbstverständlich, daß man - auch nach Anmeldung in einem Konto mit sudo-Gruppenzugehörigkeit, keine Admin-Rechte hat, solange man sich nicht über sein Paßwort dafür qualifiziert. Ebenso ist es eine typische Erscheinung, daß gerade Windows-Umsteiger immer wieder mal danach fragen, wie man sich im grafischen System als root anmeldet. Daß das abgeschaltet ist, hat seinen guten Grund.
Zitat von: Wikipedia
Der wohl größte Vorteil ist aber die dadurch gesicherte Wahrung der Systemintegrität bei Benutzung ohne Administrationsrechte. Ein Schadprogramm kann sich nur soweit verbreiten, wie die Schreibrechte des Benutzers reichen.
Das ist es, was ich mit Selbstschutz des Systems beschrieben habe.
Legt man nun Programme zur Ausführung im Home ab, wird dieser Selbstschutz brutal umgangen. Die Sicherheit bei diesen Programmen ist wieder auf dem Stand vor 20 Jahren. Denn wenn Benutzerrechte reichen, um diese Dateien zu verändern, so hat sie auch ggfs. der erfolgreiche Angreifer.

Der Grund diese Programme nach /opt zu verschieben besteht darin, daß /opt ein Systemordner in dem eben nur root Schreibrechte hat. Damit ist das Sicherheitsproblem gelöst. Der zweite Grund für /opt besteht darin, daß dieser Ordner von der Paketverwaltung nicht verwendet wird. Damit ist also ausgeschlossen, daß in /opt abgelegte Programmdateien plötzlich verloren gehen. Für die praktische Verwendung erstellt man nach dem Verschieben in /opt (pro Programm ein eigener Ordner) eine Verknüpfung von der ausführbaren Startdatei in den Ordner /usr/bin und hat das Programm automatisch im Pfad, kann das Programm also ohne Pfadangabe durch einfachen Programmaufruf aus dem Terminal starten. Wahlfrei ust natürlich auch die Erstellung einer .desktop-Datei möglich (Letzteres sprengt allerdings das Thema hier und ist nur der Vollständigkeit halber angemerkt.)

speichere ich unter ~/.local/bin
wobei ~/.local/bin dann noch anzulegen wäre denn unter Mint18.2 ist bin hier standardmäßig nicht vorhanden.
« Letzte Änderung: 05.11.2017, 15:59:42 von kuehhe1 »

Zitat von: Wikipedia
Der wohl größte Vorteil ist aber die dadurch gesicherte Wahrung der Systemintegrität bei Benutzung ohne Administrationsrechte. Ein Schadprogramm kann sich nur soweit verbreiten, wie die Schreibrechte des Benutzers reichen.
Das ist es, was ich mit Selbstschutz des Systems beschrieben habe.
Legt man nun Programme zur Ausführung im Home ab, wird dieser Selbstschutz brutal umgangen. Die Sicherheit bei diesen Programmen ist wieder auf dem Stand vor 20 Jahren. Denn wenn Benutzerrechte reichen, um diese Dateien zu verändern, so hat sie auch ggfs. der erfolgreiche Angreifer.

Der Grund diese Programme nach /opt zu verschieben besteht darin, daß /opt ein Systemordner in dem eben nur root Schreibrechte hat. Damit ist das Sicherheitsproblem gelöst.
Danke Cosmo, für die ausführliche Erklärung. Irgendwie alles logisch, kommt mir auch deja vu-mässig bekannt vor ;-) . Allerdings habe ich da wieder folgenden Knoten im Kopf: Wenn der erfolgreiche Angreifer es geschafft hat, in den Besitz des Passworts des users mit sudo-Gruppenzugehörigkeit zu kommen und sich damit anzumelden, dann kann er doch auch mit sudo rootrechte erlangen, da das Passwort ja das gleiche ist. Wo ist dann der Schutz?

Auch diese Frage kommt mir vor wie ein deja-vu. Irgendwann hatte ich mal gemeint, das Thema verstanden zu haben. Hier bin ich mir nicht mehr wirklich sicher :-)

Vielleicht ist das auch nur ein Typo und gemeint ist: /usr/local/bin, das ist ein Standard-Verzeichnis.

Legt man nun Programme zur Ausführung im Home ab, wird dieser Selbstschutz brutal umgangen. Die Sicherheit bei diesen Programmen ist wieder auf dem Stand vor 20 Jahren. Denn wenn Benutzerrechte reichen, um diese Dateien zu verändern, so hat sie auch ggfs. der erfolgreiche Angreifer.
Ist doch nur eine Wiederholung des bereits geschriebenen Textes.
Über die (historischen) Schwächen des Fenster-Systems brauchen wir hier doch nicht weiter zu debattieren.
Meine Frage richtete sich auf die Rechte-Verwaltung bei LINUX.
Nun wäre ich sehr dankbar für eine etwas ausführlichere und sachlich begründete Erklärung, warum das ein so großes Risiko darstellen soll.
Denn zu Windows 98 will ich wahrlich nicht zurück.

Welche Rechte oder auch andere Maßnahmen wären denn dann für Dateien in ~/bin zu empfehlen, um das Risiko so gering wie möglich zu halten?
Mal vorausgesetzt, es ist überhaupt eine Option, dort etwas abzulegen.

Dass /opt ein bevorzugter Ort für zusätzliche Software ist, habe ich doch nicht in Frage gestellt.
Trotzdem ist es in manchen Fällen auch durchaus üblich, diese im "Home" abzulegen (siehe AppImage).
Was daran so furchtbar schrecklich sein soll, sehe ich immer noch nicht ein.

ZeckeSZ

  • Gast
Der Grund diese Programme nach /opt zu verschieben besteht darin, daß /opt ein Systemordner in dem eben nur root Schreibrechte hat. Damit ist das Sicherheitsproblem gelöst.
Wenn du dir AW #8 von Nessie ansiehst, dann ist es das wohl eher nicht. Es funktioniert genau so einfach wie beschrieben, z.B. Datei oder komplettes Verzeichnis ins ~ kopieren und darin dann das Programm aufrufen - läuft (hier ausprobiert mit Verzeichnis master-pdf-editor-4). Und zum Besitzer bin ich mit dieser Aktion auch geworden. An die Möglichkeit hatte ich gar nicht gedacht, als ich meinen ersten Beitrag verfasste.

wobei ~/.local/bin dann noch anzulegen wäre denn unter Mint18.2 ist bin hier standardmäßig nicht vorhanden
Genau so wie du ~/bin anlegen müsstest...

Wir machen alle den «Fehler» und haben keine separate Home-Partition, die mit noexec in der /etc/fstab steht.  :P Dann könnte man aus einem Benutzerverzeichnis nichts starten.

Alternativ könnte man mit apparmor (oder SELinux) das System dermaßen zu konfigurieren, dass man erst eine Viertelstunde Arbeit investieren müsste, ehe etwas zusätzliches startet. ;)

Möchte das jemand? Ein System, dass so sicher ist, dass es schon weh tut.