staging.inyokaproject.org

Guten Tag zusammen.

Ich habe versucht, wie im Artikel beschrieben einem bestimmten Nutzer die Möglichkeit zu geben, ein bestimmtes Skript ohne Passworteingabe auszuführen. Die im Artikel vorgeschlagene Syntax

BENUTZERNAME ALL = NOPASSWD: /pfad/zum/skript

funktionierte nicht (→ Syntaxfehler).

In dieser Anleitung:

http://ubuntuforums.org/showthread.php?t=1505447

wird diese Syntax ohne Leerzeichen verwendet: BENUTZERNAME ALL=NOPASSWD:/pfad/zum/skript

Und damit funktioniert es bei mir (Ubuntu 14.04). Hat sich seit der Entstehung des Artikels die Syntax verändert?

Gruß

Frl. Schmidt

Bei 14.04 geht eigentlich beides, aber in der man stand es glaub anders als im Wiki.

Hallo,

in man sudoers steht es (unter 14.04) auch mit Leerzeichen.

@Frl. Schmidt: was war denn die Fehlermeldung?

Gruß, noisefloor

Im Abschnitt „Root-Passwort einrichten“ steht: „[...] allerdings ist es unter Verwendung von sudo nach wie vor möglich, Root-Rechte zu erlangen.“

Es sollte noch erwähnt werden, dass man auch über das PolicyKit z.B. mittels pkexec nach wie vor mit dem Benutzerkennwort root-Privilegien erhalten kann. Abhilfe schafft hier beispielsweise

1

sudo cp -p /etc/polkit-1/localauthority.conf.d/50-localauthority.conf /etc/polkit-1/localauthority.conf.d/60-root.conf

Allerdings zögere ich, diesen Hinweise in diesem Artikel unterzubringen, der sich ja nur auf sudo bezieht.

Habt ihr da einen Vorschlag?

Hallo,

Allerdings zögere ich, diesen Hinweise in diesem Artikel unterzubringen, der sich ja nur auf sudo bezieht.

Richtig gezögert ☺

Habt ihr da einen Vorschlag?

Das Vorgehen in den PolicyKit Artikel einbauen und wenn alles fertig ist in den sudo-Artikel ggf. einen Hinweis einbauen.

Gruß, noisefloor

noisefloor schrieb:

Das Vorgehen in den PolicyKit Artikel einbauen und wenn alles fertig ist in den sudo-Artikel ggf. einen Hinweis einbauen.

So ist es geschehen. Kannst du einmal drüberschauen?

Hallo,

ein eigener Unterabschnitt im Polkit Artikel mit einem kleinen bisschen mehr Text wäre besser - im Moment geht es im eher Kontext unter und ist damit schwer zu finden.

Gruß, noisefloor

Root-Anmeldung untersagen

Hat man einmal dem root-Benutzer ein Passwort gegeben und möchte dies wieder rückgängig machen, so kann man mit dem Befehl

sudo passwd -d root

den Account wieder in den "deaktivierten" Zustand bringen.

Der Satz suggeriert, dass man mit dem Befehl den Zustand wiederherstellt, der bei einer Neuinstallation ohne root-Passwort vorhanden ist. Das ist aber nicht der Fall. Vor dem Einrichten eines root-Passworts enthält die Datei /etc/shadow im Passwort-Feld ein einzelnes Ausrufezeichen "!", nach obigem Befehl ist das Feld leer.

Der früher hier in der Diskussion vorgeschlagene Befehl

sudo passwd -dl root

stellt eben diesen Ausgangszustand mit "!" wieder her.

fu-sin schrieb:

... Update: mit sudo passwd -dl root wie in CommunityHelpWiki steht, wird das o.g. Problem behoben und auch der Zugang zum root-Recovery-Modus wird nicht gesperrt (wenn ich richtig verstanden habe, worum es geht. s. Anhang).

Im Netz habe ich auch den Befehl "sudo usermod -p '!' root" gefunden, habe ich aber nicht getested.

Wenn kein Einwand kommt, werde ich demnächst den Befehl im Wiki korrigieren.

edit: done

Achtung!

Man sollte die Passwortabfrage nur für Skripte oder Programme deaktivieren, die in einem Systemverzeichnis (/bin, /sbin, /usr/bin, /usr/sbin, ...) liegen und root gehören. Grund: Ist die Passwortabfrage beispielsweise für das Skript ~/bin/mein-skript deaktiviert, dann kann es ein Angreifer mit Benutzerrechten einfach löschen und durch ein beliebiges Skript oder Programm ersetzen und dann mit Root-Rechten ausführen. Auf diese Weise wäre das gesamte System kompromittiert. Erst wenn das Skript root gehört und nur von root geändert werden kann und auch in einem Verzeichnis liegt, in dem nur root Schreibrechte hat, ist dieser Angriff nicht mehr möglich.

Was wäre denn z.B. mit folgendem Eintrag:

bob ALL = (eve) NOPASSWD: /home/eve/mein-skript

Angenommen bob ist in der sudo Gruppe, /home/eve/mein-skript hat eve als owner, gehört also nicht root.

Wenn ein Angreifer es dadurch schafft, /home/eve/mein-skript durch ein bösartiges Script zu ersetzen, kann dieses im schlimmsten Fall immer nur mit User Eve ohne Passwort-Abfrage ausgeführt werden. Das Risiko hängt hier also von Eve's Rechten ab, welche auf ein Minimum reduziert werden können.

Obiges Zitat sollte daher meiner Meinung nach in der Hinsicht relativiert werden, dass alternativ z.B. der Nutzer eingegrenzt wird (wie oben im Beispiel durch (eve)).

Sehe ich das richtig?

Hallo,

ich verstehe dein anliegen nicht... Es geht doch eben darum, dass man das _nicht_ für Skripte unterhalb vom /home/BENUTZER setzt. Genau darauf zielt dein Beispiel aber ab?

Gruß, noisefloor

Hallo,

ja, mehr oder weniger: Es geht mir darum, eine Alternative für Programme mit deaktivierter Passwortabfrage aufzuzeigen, die man eben nicht in System-Verzeichnissen und einem root Owner ablegen möchte, sondern beispielsweise unterhalb des eigenen HOME Verzeichnisses.

Im Zitat ist der Angriffsvektor, dass ein Skript mit Benutzerrechten ausgetauscht werden und dann mittels sudo als root ohne Passwortabfrage ausgeführt werden kann.

Stattdessen kann man aber auch die effektive User Id des sudo Eintrags auf einen bestimmten Benutzer (vorzugsweise mit minimalen Rechten) beschränken. Zwar könnte das Skript ausgetauscht werden (da user owner), jedoch wäre die Passwortabfrage nur für Eve deaktiviert, nicht für root.

Gruß n5z

Hallo,

sorry, kann ich immer noch nicht nachvollziehen - was in /home liegt, braucht doch normalerweise _keine_ Root-Rechte, sondern "nur" Benutzerrechte. Wenn in /home irgendwas liegt, was (zwingend) Root-Rechte braucht, hat man doch vorher schon was falsch gemacht?!

Gruß, noisefloor

Prinzipiell stimme ich dir zu - aber sudo ist ja auch für den normalen Benutzerwechsel da, und nicht nur um Root-Rechte zu erlangen. Quasi das Pendant zu su - hier muss jedoch das Passwort des Ziel-Nutzers bekannt sein, bei sudo reicht das aktuelle Nutzer PW.

Hallo,

aber sudo ist ja auch für den normalen Benutzerwechsel da, und nicht nur um Root-Rechte zu erlangen.

Steht ja auch so in der Einleitung.

Aber ich verstehe immer nicht, worauf die hinaus willst bzw. was der konkrete Use-Case sein soll. Wenn jemand Mitglied (bei dir: bob) der Gruppe sudo ist, man aber verhindern will, dass bob Skripte von anderen Nutzern (bei dir: eve) ausführt, dann hat man doch auch _vorher_ den Fehler gemacht, als man bob zur Gruppe sudo hinzugefügt hat?

Man kann sicherlich 5000 verschiedene Angriffsszenarien mit root/sudo/Nutzerechen konstruieren - aber die müssen ja nicht alle hier im Wiki aufgeführt werden, wenn der praktischen Nutzen ein Nischenfall ist.

Vielleicht kommt ja hier noch jemand vorbei, der einen tieferen praktischen Sinn in deinem Vorschlag sieht. Ich verstehe es jedenfalls nicht.

Gruß, noisefloor

Konkretes Beispiel:

Eine portable Firefox Installation (oder andere User-bezogene Anwendung in HOME) mit separatem browser user und NOPASSWD ausführen. Damit ist die Anwendung vom aktuellen Benutzer, seiner Rechte, und sensibler Daten in HOME entkoppelt und bietet ein Stück mehr Sicherheit - zusätzlich zu anderen Vorkehrungen wie AppArmor or SELinux.

Den Wiki-Artikel an sich finde ich gut gelungen. Mir kommt nur die Formulierung

Man sollte die Passwortabfrage **nur** für Skripte oder Programme deaktivieren, die in einem Systemverzeichnis (/bin, /sbin, /usr/bin, /usr/sbin, ...) liegen und root gehören.

ein wenig zu alternativlos vor. Die aufgeführte Variante sollte vergleichbare Sicherheit bieten. Außerdem halte ich es generell für eine bessere Idee, die effektive User Id vom sudoers-Eintrag im Vorhinein zu beschränken (im Artikel wurde soweit immer (ALL) verwendet). Natürlich hast Du Recht, dass die Analyse aller Szenarien den Artikel-Rahmen sprengen würden.

Vielleicht mag der Kommentar ja dem ein oder anderen helfen, der über die gleiche Stelle stößt.

Gruß n5z