sudo vermeiden

[GregorS]

Hi zusammen!

Ich kam vorhin auf eine irgendwie lustige Möglichkeit, sudo zu vermeiden. Ich hätte das jetzt benötigt, um /var/log/syslog lesen zu können, ohne root oder Mitglied der Gruppe adm sein zu müssen.

Lösung:
SSH ist bei mir sowieso auf allen Rechnern istalliert. Also habe ich als root

Code: Alles auswählen

cat /home/$USER/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys

gemacht und kann jetzt als $USER

Code: Alles auswählen

ssh root@localhost 'tail -n 1 /var/log/syslog'

machen.

Ich kann also damit weitermachen, sudo zu meiden

Schönen Sonntach noch!

Gregor

[HumiNi]

Es mag zwar eine irgendwie lustige Idee sein, aber ich kann den Mehrwert nicht erkennen, dafür einen ssh-Tunnel nach localhost zu graben.
Wenn den jemand erkennt, bitte ich um Erleuchtung.

[JTH]

Das klingt lustig, aber nicht nach einer allgemein empfehlenswerten Idee, nur um auf eine lokale Logdatei zugreifen zu können. Damit hast du deinem Benutzer (fast) uneingeschränkte root-Rechte gegeben. Womöglich sogar interaktionsfrei (ohne Legitimation) – nämlich, wenn dein SSH-Key nicht mit einer Passphrase versehen ist.

Du könntest jetzt auch ein schönes

Code: Alles auswählen

ssh root@localhost 'rm -fr --no-preserve-root /'

absetzen. Das kommt einem sudoers-Eintrag inklusive ALL und NOPASSWD gleich.

Ein

Code: Alles auswählen

adduser $USER adm

ist doch wesentlich spezifischer und ungefährlicher.

[GregorS]

Hallo ihr beiden,

für mich geht es hauptsächlich um die Vermeidung von sudo. Das alles spielt sich in meinem kleinen Heimnetz ab, das keine Verbindung zu irgendwelchen Atomkraftwerken hat. Mir ist klar, dass das „Loch“ riesig ist, das ich dadurch gerissen habe. Als wirklich „gefährlich“ würde ich das aber nicht bezeichnen.

Gruß

Gregor

[cosinus]

Wenn der User über einen kleinen Umweg per SSH ohne Passwort wie root agieren darf, seh ich da eigentlich keinen Unterschied mehr, gleich direkt als root alles zu machen.
Wäre es nicht einfacher und sicherer, die syslog-Datei lesbar zu machen, also auf 644 zu setzen?

[GregorS]

Wenn der User über einen kleinen Umweg per SSH ohne Passwort wie root agieren darf, seh ich da eigentlich keinen Unterschied mehr, gleich direkt als root alles zu machen.
Wäre es nicht einfacher und sicherer, die syslog-Datei lesbar zu machen, also auf 644 zu setzen?

Ja, nur ist es keine Seltenheit, dass irgendetwas daherkommt und meint, so etwas korrigieren zu müssen. Und wie ist es denn z.B., wenn logrotate syslog „wegrotiert“ und syslog dann neu angelegt wird? Hat es dann nicht automatisch wieder 640-Rechte?

Gruß

Gregor

[KP97]

Journalctl kann auch vom User ausgeführt werden. Einfach den User der Gruppe systemd-journal zufügen.
Ganz ohne sudo und anderen Verrenkungen tut auch doas den Job.

[TRex]

Hallo ihr beiden,

für mich geht es hauptsächlich um die Vermeidung von sudo. Das alles spielt sich in meinem kleinen Heimnetz ab, das keine Verbindung zu irgendwelchen Atomkraftwerken hat. Mir ist klar, dass das „Loch“ riesig ist, das ich dadurch gerissen habe. Als wirklich „gefährlich“ würde ich das aber nicht bezeichnen.

Gruß

Gregor

Nach der Argumentation kann ich nicht anders als zu fragen: warum wolltest du nochmal kein sudo?

[Livingston]

su -c 'tail -n 1 /var/log/syslog'

[GregorS]

Hallo ihr beiden,

für mich geht es hauptsächlich um die Vermeidung von sudo. Das alles spielt sich in meinem kleinen Heimnetz ab, das keine Verbindung zu irgendwelchen Atomkraftwerken hat. Mir ist klar, dass das „Loch“ riesig ist, das ich dadurch gerissen habe. Als wirklich „gefährlich“ würde ich das aber nicht bezeichnen.

Gruß

Gregor

Nach der Argumentation kann ich nicht anders als zu fragen: warum wolltest du nochmal kein sudo?

Warum, meinst Du denn, mag ich sudo nicht? Hatte ich das irgendwo erwähnt?

Gruß

Gregor

[cosinus]

Ja, nur ist es keine Seltenheit, dass irgendetwas daherkommt und meint, so etwas korrigieren zu müssen. Und wie ist es denn z.B., wenn logrotate syslog „wegrotiert“ und syslog dann neu angelegt wird? Hat es dann nicht automatisch wieder 640-Rechte?

Müsste man mal ausprobieren. Wenn das zu umständlich ist, dann einfach deinen User zur Gruppe adm hinzufügen.

[cosinus]

Warum, meinst Du denn, mag ich sudo nicht? Hatte ich das irgendwo erwähnt?

Du willst sudo vermeiden, weil du es so sehr magst?

[TRex]

Warum, meinst Du denn, mag ich sudo nicht? Hatte ich das irgendwo erwähnt?

für mich geht es hauptsächlich um die Vermeidung von sudo.

Von "mögen" hab ich ja auch nix gesagt - aber wenn man irgendwas vermeiden will, hat das ja (außer bei psychischen Problemen) einen Grund, und bei sudo ist's meistens security, gefolgt von "neumodischer Ubuntu-Kram". Das Bestreben, Konzepte zu verbessern, kann ich nachvollziehen, aber ich verwende teilweise sudo ohne Passwort mit deiner Begründung. Da wäre dein Ansatz sogar theoretisch sicherer, wenn ich zur Legitimation meinen ssh-Agent zur besagten Maschine durchschleife

[chrbr]

Hallo GregorS,
Deine Idee fand ich auf den ersten Blick bestechend. Interessant ist es auf jeden Fall. Ich habe daraufhin mal folgendes ausprobiert.

In einem User-Terminal lasse ich netcat auf UDP und dem Port 1234 lauschen.

Code: Alles auswählen

 nc -l -u -p 1234

Als root wird nun das Journal über eine Pipe an einen zweiten netcat geschickt, der den Stream über UDP sendet.

Code: Alles auswählen

journalctl -f|nc -u 127.0.0.1 1234

Und schwups - man sieht die fortlaufenden Logeinträge im User Terminal. Ohne Deinen Vorschlag hätte ich das nie probiert .Ich habe netcat-traditional installiert. https://manpages.debian.org/bullseye/ne ... .1.en.html zeigt noch andere Pakete, die sich damit aber nicht vertragen.
Viele Grüße,
Christoph

[GregorS]

Deine Idee fand ich auf den ersten Blick bestechend.

Auf den zweiten Blick wird mir immer klarer, dass das Loch, dass ich da aufreiße, doch ganz schön groß ist und mir nichts Anderes übrig bleibt, mir mal anzugucken, was ein 'adm' darf (oder nicht). Irgendeine Ablenkung von den Sachen, die ich gerade am Köcheln habe, kann ich halt grad gar nicht brauchen. Zumal am WE.

Was soll's. Ich hab' den C64 überlebt. Da ist man gut im Nehmen.

Gruß

Gregor

[JTH]

Anderes übrig bleibt, mir mal anzugucken, was ein 'adm' darf (oder nicht).

Die Gruppe adm sollte dir hier wirklich sehr gelegen kommen. Da gibt's eigentlich nicht viel zu überlegen

adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.

[GregorS]

adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.

Da zeigt sich wieder einmal, dass ein Blick in die Geschichte manchmal echt hilfreich sein kann Danke!

Gregor

PS: Ui, als ich diese Liste zuletzt gesehen habe, war sie etwas kürzer ...

[uname]

Ich finde es immer interessant, wenn man sich alternative Ansätze überlegt auch wenn diese im Beispiel vom Austauschen von sudo durch SSH-Keys nicht unbedingt zielführend sind. Man kann aber mit "command=" die SSH-Keys auch einschränken. Wäre vielleicht noch eine Alternative.

command="cmd"
Forces a command to be executed when this key is used for authentication. This is also called command restriction or forced command. The effect is to limit the privileges given to the key, and specifying this options is often important for implementing the principle of least privilege. Without this option, the key grants unlimited access as that user, including obtaining shell access.

Zudem ist sudo keine schlechte Sache, sondern eine Sicherheitsfunktion. sudo wird bei Ubuntu (und auch je nach Installation auch Debian) zu großzügig ausgelegt. sudo war seinerzeit ganz anders gedacht als es noch echte Mehrbenutzersysteme gab. Da gab es z. B. Benutzer oder Benutzergruppen, die nur ganz spezielle Aufgaben und diese teilweise über sudo als root ausführen sollten.

[HumiNi]

Ich war mal Mitglied eines Admin-Teams, die Linux-Server in hoher dreistelliger Anzahl betreut haben. Schon aus audit-Gründen hat keiner als root gearbeitet (das generierte root-Passwort war unbekannt und lag für Notfälle im RZ verschlossen in einem Umschlag). Alles lief über sudo und wurde ID-bezogen protokolliert.

[Meillo]

Ich finde es immer interessant, wenn man sich alternative Ansätze überlegt auch wenn diese im Beispiel vom Austauschen von sudo durch SSH-Keys nicht unbedingt zielführend sind. Man kann aber mit "command=" die SSH-Keys auch einschränken. Wäre vielleicht noch eine Alternative.

command="cmd"
Forces a command to be executed when this key is used for authentication. This is also called command restriction or forced command. The effect is to limit the privileges given to the key, and specifying this options is often important for implementing the principle of least privilege. Without this option, the key grants unlimited access as that user, including obtaining shell access.

Zudem ist sudo keine schlechte Sache, sondern eine Sicherheitsfunktion. sudo wird bei Ubuntu (und auch je nach Installation auch Debian) zu großzügig ausgelegt. sudo war seinerzeit ganz anders gedacht als es noch echte Mehrbenutzersysteme gab. Da gab es z. B. Benutzer oder Benutzergruppen, die nur ganz spezielle Aufgaben und diese teilweise über sudo als root ausführen sollten.

Danke fuer diesen Beitrag. Die Kopplung eines SSH-Keys an einen Befehl ist die entscheidende Ergaenzung zum Ansatz von GregorS. Auch die differenziertere Betrachtung von sudo finde ich gut. Denn waere sudo in jeder Weise schlecht, dann waere es nie so verbreitet geworden. Es ist ein Hilfsmittel, das sinnvoll eingesetzt werden kann, aber nicht in jedem Fall sinnvoll ist. Sicherheitsthemen beduerfen immer differenzierter Betrachtungen.