doas unter FreeBSD

Es geht gar nicht primär um das Reboot, was ich als normaler User machen kann, sondern darum:
Um den Bug zu beschreiben ja, aber das Verhalten von doas wäre ziemlich eigenartig, wenn eine abgeänderte PATH dazu führen kann das Befehle ignoriert werden, weil es zufällig schonmal früher in der PATH gefunden wurde
 
Ich empfand es komisch, dass wenn ich nur den Namen einer ausführbaren Datei in der doas.conf angebe, dies anscheinend für die erste Datei gilt die er im Pfad findet. Das schien mir ein Sicherheitsproblem zu sein woraufhin mich @mogbo auf folgende Seite hinwies: https://www.tedunangst.com/flak/post/doas-mastery
Ich habe das mal durch den Google Übersetzer gejagt, weil nicht jeder fließend englisch kann:

doas beherrschung

Es ist ein Jahr seit der Einführung von Doas, also ist es eindeutig Zeit, ein Buch zu schreiben. Oder vielleicht eine Broschüre.

UNIX-Systeme haben zwei Klassen von Benutzer, die Super-Benutzer und regelmäßige Benutzer. Der Superuser ist super, und alle anderen sind nicht. Diese Kraftkonzentration hält die Dinge einfach, bedeutet aber auch, dass oft zu viel Kraft gewährt wird. In der Regel brauchen wir nur Super User Powers, um eine Aufgabe durchzuführen. Wir hätten lieber keine solche Kraft. Denken Sie an die Verantwortung, die mitbringen würde! Wie das Sudo-Kommando erlaubt doas die Unterteilung von Superuser-Privilegien und gewährt ihnen nur für bestimmte Aufgaben.

Der doas Befehl selbst hat ein paar Optionen, die wir später etwas diskutieren werden, aber der interessanteste Teil ist die Konfigurationsdatei. Hier ist die echte Magie.

doas.conf

Die einfachste mögliche doas.conf config ist wirklich ganz einfach. Blinzeln Sie nicht oder Sie werden es vermissen.

Die leere config macht nichts, erlaubt uns aber, den Standardregelsatz zu besprechen. Da ist gar nichts. doas beginnt mit der Auswertung von Regeln im DENY-Zustand. Wenn keine Regeln übereinstimmen, wird die Aktion verweigert. Stimmt. Sogar Root erhält einen Berechtigungsverweigerungsfehler. Dies ist nicht besonders nützlich, per se, aber man kann sicher sein, dass das Lesen der installierten doas.conf-Datei ausreicht, um das Systemverhalten vollständig zu verstehen.

Wenn es überhaupt keine Konfigurationsdatei gibt, wird Doas nach dem Drucken einer Nachricht beenden, dass es nicht aktiviert ist.

Die einfachste nützliche Konfiguration sieht wahrscheinlich eher so aus.

Genehmigung: Rad

Damit kann jeder Benutzer in der Radgruppe einen Befehl als root ausführen. Es entspricht etwa dem su-Befehl. Für eine vollständigere Emulation möchten wir root erlauben, Befehle ohne Passwort auszuführen.

Genehmigung: Rad
erlaube nopass keepenv root

Wir addieren die Wurzelregel zweitens, weil doas Regeln in einer letzten Matchweise auswertet. Wurzel ist in der Radgruppe, also wird die erste Regel übereinstimmen, und dann müssen wir das mit einer zweiten Regel überschreiben. Denken Sie daran, immer mit allgemeinen Regeln beginnen, dann machen sie mehr spezifisch.

Warum gehst du auch als Wurzel? Denn manchmal möchten Sie zu einem weniger privilegierten Benutzer wechseln. Oder Sie haben ein Skript, das doas verwendet, um Privilegien für eine wichtige Operation zu erhöhen, aber Sie sind bereits root, wenn Sie es ausführen.

passwörter

Das Standardverhalten von doas ist die Authentifizierung jedes Mal, wenn der Benutzer einen Befehl ausführt. Normalerweise bedeutet dies, dass sie ihr Passwort eingeben. Dies kann mühsam werden, wenn mehrere Befehle ausgeführt werden. Es gibt zwei Schlüsselwörter, die einer doas.conf-Regel hinzugefügt werden können, um diese Anforderung zu ändern.

Das Hinzufügen des nopass-Schlüsselwortes zu einer Regel bedeutet, dass der Benutzer immer erlaubt ist, den Befehl ohne Eingabe eines Passworts auszuführen. Wir haben das oben in der Regel für Wurzel gesehen. Der Benutzer ist bereits root, also können sie alles tun, was sie mögen und es gibt keinen Grund, ein Passwort zu erfordern.

Durch das Hinzufügen des persist-Schlüsselwortes wird sich das Doas daran erinnern, dass der Benutzer zuvor authentifiziert wurde und keine weitere Bestätigung für ein Timeout von fünf Minuten erfordert.

erlauben persist: Rad

Diese Regel erstellt die gemeinsame Sudo-Konfiguration, die ein Passwort für Radbenutzer erfordert, wenn das erste Mal ein Befehl ausgeführt wird.

Die Authentifizierungsinformationen werden im Kernel aufgezeichnet und an die aktuelle Sitzung angehängt. Im Gegensatz zu Dateisystemkarten ist es für andere Benutzer nicht zugänglich und schwer zu fälschen. Das Timeout wird immer in Echtzeit stattfinden, nicht Computerzeit, was bedeutet, dass die Anpassung der Systemuhr rückwärts kein neues Leben einem abgelaufenen Ticket gewähren kann. Wiederholte Ausführungen setzen das Timeout zurück, aber nur, wenn die Regel markiert ist. Regeln können nicht sowohl persist und nopass, noch werden nopass Regeln verlängern das Timeout.

Wenn Sie mehrere Shell-Logins zu einer Maschine haben, erfordert jede Anmeldung eine Authentifizierung. Darüber hinaus enthält die Authentifizierungsinformation die übergeordnete Shell-Prozess-ID. Das bedeutet, dass die Ausführung von Doas in einem Shell-Skript eine Authentifizierung erfordert. Oder, um einen anderen Weg zu wiederholen, wenn Sie ein Skript oder Programm von unsicherer Qualität ausführen, wird es nicht in der Lage sein, Stille zu erheben Privilegien. (Das ist die Theorie sowieso. In der Praxis verlässt der Scheck ganz wackelnde Zimmer.)

erlauben persist: Rad
Genehmigung: Rad cmd reboot

Authentifizierungsprüfungen werden nur für die markierten Regeln übersprungen. Um Fehler zu vermeiden, können wichtige Befehle ohne fortbestehen, um immer ein Passwort zu erfordern.

Die Befehlszeilenoption -L-Befehlszeilenoption ist analog zum Abmelden und löscht sofort alle beharrten Authentifizierungsinformationen in diesem Terminal, ohne auf das Timeout zu warten.

Umwelt

Es gibt zwei grundlegende Möglichkeiten, um Informationen zu ausgeführten Befehlen zur Verfügung gestellt. Die erste und offensichtlichste ist die Kommandozeile. Der zweite und weniger sichtbare Weg ist über Umgebungsvariablen. Obwohl es sich um unsichtbar handelt, können Umweltvariablen dramatische Auswirkungen auf das Verhalten eines Programms haben. Daher ist es wichtig, dass doas eine Filterung bietet, um unbeabsichtigte Konsequenzen zu vermeiden. Standardmäßig wird nur eine kurze Liste von Variablen kopiert.

Es gibt zwei config Schlüsselwörter, die sich auf die Umgebung, keepenv und setenv beziehen. Das erste ist sehr einfach. Wir haben es vorher gesehen, in der Regel für Wurzel oben. Keepenv bedeutet einfach, dass die gesamte Umgebung beibehalten und weitergegeben werden soll, wie es der ausgeführte Befehl ist. Dies ist eine bequeme Verknüpfung für vertrauenswürdige Benutzer.

Die Verwendung von setenv ist ein wenig komplizierter, da es eine Kombination aus Hinzufügen, Ändern und Löschen von Umgebungsvariablen ermöglicht. Schauen wir uns ein Beispiel an.

erlauben setenv {PKG_PATH ENV = / root / .kshrc PS1 = $ DOAS_PS1} zoltan

Diese Regel erlaubt es zoltan, Befehle als root auszuführen. Die PKG_PATH-Umgebung bleibt erhalten. Die ENV-Umgebung, die auf eine Konfigurationsdatei für ksh verweist, wird auf einen von Root umgewandelt. Schließlich überschreiben wir die PS1-Einstellung, die die Eingabeaufforderung der Shell steuert. Wir geben den neuen Wert in dieser Konfigurationsdatei nicht an, sondern verwenden statt dessen den Wert in DOAS_PS1. Damit kann zoltan die Root-Eingabeaufforderung wie gewünscht anpassen.

Benutzer und Ziele

Jede Regel in doas.conf gilt für eine Person oder Gruppe, die nach Genehmigung und Optionen angegeben ist. Es gibt kein Schlüsselwort, um zwischen Benutzern und Gruppen zu unterscheiden. Stattdessen wird Syntax ähnlich chown verwendet, mit Benutzernamen selbst oder: Gruppennamen mit einem führenden Doppelpunkt. Jetzt ist eine gute Zeit für eine Erinnerung, dass Regeln immer ausgewertet werden, um mit der letzten Matching-Regel gewinnen. Spezifische Benutzerregeln werden nicht automatisch über Gruppenregeln bevorzugt, es sei denn, sie kommen später in der Datei.

In den meisten Situationen wird doas verwendet, um Befehle als root auszuführen. Dies erfordert keine zusätzliche Syntax. Allerdings können wir auch einige Regeln auf bestimmte Benutzer beschränken.

erlaube nopass zoltan als dbadmin

Diese Regel lässt zoltan die Befehle als Datenbankadministrator ohne Eingabe eines Passworts ausführen, erlaubt aber nicht, dass zoltan alles als root ausführt.

Befehle

Wir sind am Ende unserer Tour durch die doas.conf Syntax. Doas können auch eingeschränkt werden, so dass Regeln nur für bestimmte Befehle oder sogar bestimmte Befehle mit bestimmten Argumenten gelten.

erlauben nopass: operator cmd reboot

Normalerweise benötigt der Neustart root-Berechtigungen. Es wird stattdessen indirekt durch das setuid Programmabschaltung ausgeführt, dessen Ausführung auf die Operatorgruppe beschränkt ist. Die oben genannte Regel ermöglicht es diesen Benutzern, einen Neustart direkt auszuführen. Allerdings können die Operatoren nicht in der Lage sein, andere Befehle als root auszuführen oder eine Shell zu erhalten.

erlauben zoltan cmd sh args / etc / netstart

Hier erlauben wir es dem Zoltan, das Netstart-Skript zu starten, das Netzwerkschnittstellen konfiguriert. Wir geben keine Zoltan-Erlaubnis, irgendeinen Shell-Befehl auszuführen, nur das Netstart-Skript.

In diesen beiden Beispielen wurde das cmd nur mit dem Basisnamen angegeben. In diesen Fällen beschränkt sich doas nur auf Befehle im System PATH (/ bin: / sbin: / usr / bin: / usr / sbin: / usr / local / bin: / usr / local / sbin). Zoltan wird nicht in der Lage sein, eine Binärdatei in seinem Heimatverzeichnis zu installieren und PATH auf ~ / bin zu setzen, um unsere Absichten zu untergraben. Absolute Pfadnamen können auch angegeben werden, aber der Benutzer wird auch verpflichtet, sie vollständig auszutauschen.

Alle angegebenen Befehlsargumente müssen in ihrer Gesamtheit angegeben werden.

erlaube zoltan cmd ifconfig args iwm0 up
erlaube zoltan cmd ifconfig args iwm0 unten

Diese beiden Regeln erlauben es dem Zoltan, die WiFi-Schnittstelle ein- und auszuschalten, aber nicht irgendwelche anderen Parameter zu ändern.

Einige Userland-Dienstprogramme, die Informationen aus dem Kernel sammeln, stellen nur eine eingeschränkte Teilmenge von Informationen dar, wenn sie als reguläre Benutzer sind. Um die vollständigen Informationen zu sehen, muss man als root laufen. Zum Beispiel wird fstat nur minimale Informationen über Unix-Domain-Sockets drucken.

tedu Xorg 94581 16 * unix stream 0x0
tedu Xorg 94581 17 * unix stream 0x0
tedu Xorg 94581 18 * unix stream 0x0
tedu Xorg 94581 19 * unix stream 0x0
tedu Xorg 94581 20 * unix stream 0x0

Aber wenn ich wieder als Wurzel renne, sehen wir viel mehr Informationen.

tedu Xorg 94581 16 * unix stream 0xffff800000b45980 <-> 0xffff800000b3d700
tedu Xorg 94581 17 * unix stream 0xffff800000b3d880 <-> 0xffff800000b45500
tedu Xorg 94581 18 * unix stream 0xffff800000b45480 <-> 0xffff800000b45300
tedu Xorg 94581 19 * unix stream 0xffff800000b45080 <-> 0xffff800000128e80
tedu Xorg 94581 20 * unix stream 0xffff800000b60280 <-> 0xffff800000b60780

Dies ermöglicht es uns, diese Sockets mit dem Prozess am anderen Ende zu übereinstimmen.

tedu xterm 33159 3 * unix stream 0xffff800000b45300 <-> 0xffff800000b45480
tedu Xorg 94581 18 * unix stream 0xffff800000b45480 <-> 0xffff800000b45300

Diese Kernel-Adressen sind normalerweise verborgen, weil sie Informationen über das Speicherlayout des Kernels verraten, die verwendet werden können, um Exploits zu erleichtern, aber wenn wir Tedu vertrauen (und wer nicht wirklich?), Dann können wir dies mit einer einfachen config-Regel ändern.

erlauben nopass tedu cmd fstat args -u tedu

Mit fstat kann man immer die offenen Dateien der Prozesse anderer Benutzer sehen, aber wir geben hier Argumente an, um zu verhindern, dass Tedu Verbindungen zwischen Prozessen abbilden kann.

verweigern

Im Gegensatz zu all den erlaubten Regeln, die wir bisher gesehen haben, ist es auch möglich, eine Leugnungsregel zu erstellen, die die Befehlsausführung ausdrücklich verweigert. Diese Funktion ist besonders nützlich als Schutz gegen versehentliche Tippfehler von vertrauenswürdigen Operatoren. Es sollte nicht als Sicherheitsmerkmal verwendet werden, weil eine erschöpfende Blacklist anstrengend ist, um zu schaffen. Besser, um einen Regelsatz zu erstellen, der keine unbeabsichtigten Privilegien gewährt.

Genehmigung: Rad
verleugnen zoltan cmd reboot

Angenommen, dass zoltan im Gruppenrad ist, lassen wir ihn einen Befehl führen. Einfach nicht neu starten Vielleicht ist zoltan ein kleiner Auslöser glücklich und hat die Gewohnheit, in das falsche Terminal zu schreiben. Dieser Regelsatz wird Zoltan nicht wirklich daran hindern, die Maschine mit irgendwelchen Mitteln neu zu starten; Die erste Regel gewährt genügend Privileg, doas.conf zu bearbeiten und die zweite Regel zu entfernen, unter vielen anderen Möglichkeiten. Die Annahme ist, dass jeder auf dem gleichen Team ist.

Mach wie

Der doas Befehl selbst hat ein paar Optionen.

Da wir gerade mit der Syntax der Konfigurationsdatei fertig sind, kann die -C-Option zur Syntax verwendet werden, um eine neue Datei vor der Installation zu überprüfen. Es erlaubt auch die Überprüfung des Ergebnisses der Regelsatzauswertung für einen gegebenen Befehl und Argumente, ohne den Befehl auszuführen. Wenn wir mit dem fstat-Beispiel von früher fortfahren, können wir überprüfen, ob nur der Befehl mit Argumenten übereinstimmt.

$ doas -C doas.conf fstat
verweigern
$ doas -C doas.conf fstat -u tedu
erlauben nopass

Beim Schreiben von möglicherweise nicht interaktiven Skripten, die Doas enthalten, ist die Option -n hilfreich, um zukünftige Fehler zu verhindern. Nur nopass Regeln werden erfolgreich ausgeführt. Jede Regel, die ein Passwort erfordert, wird sofort fehlschlagen. Dies schließt alle Regeln mit dem persist Schlüsselwort ein, unabhängig davon, ob der Benutzer vor kurzem autorisiert hat.

Vielen Dank

Es wäre nicht möglich gewesen, doas ohne die Unterstützung von vielen anderen OpenBSD-Entwicklern zu beenden.
 
Ich wollte noch ergänzen, das bei mir doas unter OpenBSD das ordentlich ausführt, wozu es bestimmt ist. Es ist einfach und folgt damit der Unix Philosophie.
 
Ich habe das mal durch den Google Übersetzer gejagt, weil nicht jeder fließend englisch kann:

doas beherrschung

Es ist ein Jahr seit der Einführung von Doas, also ist es eindeutig Zeit, ein Buch zu schreiben. Oder vielleicht eine Broschüre.

UNIX-Systeme haben zwei Klassen von Benutzer, die Super-Benutzer und regelmäßige Benutzer. Der Superuser ist super, und alle anderen sind nicht. Diese Kraftkonzentration hält die Dinge einfach, bedeutet aber auch, dass oft zu viel Kraft gewährt wird. In der Regel brauchen wir nur Super User Powers, um eine Aufgabe durchzuführen. Wir hätten lieber keine solche Kraft. Denken Sie an die Verantwortung, die mitbringen würde! Wie das Sudo-Kommando erlaubt doas die Unterteilung von Superuser-Privilegien und gewährt ihnen nur für bestimmte Aufgaben.

Der doas Befehl selbst hat ein paar Optionen, die wir später etwas diskutieren werden, aber der interessanteste Teil ist die Konfigurationsdatei. Hier ist die echte Magie.

doas.conf

Die einfachste mögliche doas.conf config ist wirklich ganz einfach. Blinzeln Sie nicht oder Sie werden es vermissen.

Die leere config macht nichts, erlaubt uns aber, den Standardregelsatz zu besprechen. Da ist gar nichts. doas beginnt mit der Auswertung von Regeln im DENY-Zustand. Wenn keine Regeln übereinstimmen, wird die Aktion verweigert. Stimmt. Sogar Root erhält einen Berechtigungsverweigerungsfehler. Dies ist nicht besonders nützlich, per se, aber man kann sicher sein, dass das Lesen der installierten doas.conf-Datei ausreicht, um das Systemverhalten vollständig zu verstehen.

Wenn es überhaupt keine Konfigurationsdatei gibt, wird Doas nach dem Drucken einer Nachricht beenden, dass es nicht aktiviert ist.

Die einfachste nützliche Konfiguration sieht wahrscheinlich eher so aus.

Genehmigung: Rad

Damit kann jeder Benutzer in der Radgruppe einen Befehl als root ausführen. Es entspricht etwa dem su-Befehl. Für eine vollständigere Emulation möchten wir root erlauben, Befehle ohne Passwort auszuführen.

Genehmigung: Rad
erlaube nopass keepenv root

Wir addieren die Wurzelregel zweitens, weil doas Regeln in einer letzten Matchweise auswertet. Wurzel ist in der Radgruppe, also wird die erste Regel übereinstimmen, und dann müssen wir das mit einer zweiten Regel überschreiben. Denken Sie daran, immer mit allgemeinen Regeln beginnen, dann machen sie mehr spezifisch.

Warum gehst du auch als Wurzel? Denn manchmal möchten Sie zu einem weniger privilegierten Benutzer wechseln. Oder Sie haben ein Skript, das doas verwendet, um Privilegien für eine wichtige Operation zu erhöhen, aber Sie sind bereits root, wenn Sie es ausführen.

passwörter

Das Standardverhalten von doas ist die Authentifizierung jedes Mal, wenn der Benutzer einen Befehl ausführt. Normalerweise bedeutet dies, dass sie ihr Passwort eingeben. Dies kann mühsam werden, wenn mehrere Befehle ausgeführt werden. Es gibt zwei Schlüsselwörter, die einer doas.conf-Regel hinzugefügt werden können, um diese Anforderung zu ändern.

Das Hinzufügen des nopass-Schlüsselwortes zu einer Regel bedeutet, dass der Benutzer immer erlaubt ist, den Befehl ohne Eingabe eines Passworts auszuführen. Wir haben das oben in der Regel für Wurzel gesehen. Der Benutzer ist bereits root, also können sie alles tun, was sie mögen und es gibt keinen Grund, ein Passwort zu erfordern.

Durch das Hinzufügen des persist-Schlüsselwortes wird sich das Doas daran erinnern, dass der Benutzer zuvor authentifiziert wurde und keine weitere Bestätigung für ein Timeout von fünf Minuten erfordert.

erlauben persist: Rad

Diese Regel erstellt die gemeinsame Sudo-Konfiguration, die ein Passwort für Radbenutzer erfordert, wenn das erste Mal ein Befehl ausgeführt wird.

Die Authentifizierungsinformationen werden im Kernel aufgezeichnet und an die aktuelle Sitzung angehängt. Im Gegensatz zu Dateisystemkarten ist es für andere Benutzer nicht zugänglich und schwer zu fälschen. Das Timeout wird immer in Echtzeit stattfinden, nicht Computerzeit, was bedeutet, dass die Anpassung der Systemuhr rückwärts kein neues Leben einem abgelaufenen Ticket gewähren kann. Wiederholte Ausführungen setzen das Timeout zurück, aber nur, wenn die Regel markiert ist. Regeln können nicht sowohl persist und nopass, noch werden nopass Regeln verlängern das Timeout.

Wenn Sie mehrere Shell-Logins zu einer Maschine haben, erfordert jede Anmeldung eine Authentifizierung. Darüber hinaus enthält die Authentifizierungsinformation die übergeordnete Shell-Prozess-ID. Das bedeutet, dass die Ausführung von Doas in einem Shell-Skript eine Authentifizierung erfordert. Oder, um einen anderen Weg zu wiederholen, wenn Sie ein Skript oder Programm von unsicherer Qualität ausführen, wird es nicht in der Lage sein, Stille zu erheben Privilegien. (Das ist die Theorie sowieso. In der Praxis verlässt der Scheck ganz wackelnde Zimmer.)

erlauben persist: Rad
Genehmigung: Rad cmd reboot

Authentifizierungsprüfungen werden nur für die markierten Regeln übersprungen. Um Fehler zu vermeiden, können wichtige Befehle ohne fortbestehen, um immer ein Passwort zu erfordern.

Die Befehlszeilenoption -L-Befehlszeilenoption ist analog zum Abmelden und löscht sofort alle beharrten Authentifizierungsinformationen in diesem Terminal, ohne auf das Timeout zu warten.

Umwelt

Es gibt zwei grundlegende Möglichkeiten, um Informationen zu ausgeführten Befehlen zur Verfügung gestellt. Die erste und offensichtlichste ist die Kommandozeile. Der zweite und weniger sichtbare Weg ist über Umgebungsvariablen. Obwohl es sich um unsichtbar handelt, können Umweltvariablen dramatische Auswirkungen auf das Verhalten eines Programms haben. Daher ist es wichtig, dass doas eine Filterung bietet, um unbeabsichtigte Konsequenzen zu vermeiden. Standardmäßig wird nur eine kurze Liste von Variablen kopiert.

Es gibt zwei config Schlüsselwörter, die sich auf die Umgebung, keepenv und setenv beziehen. Das erste ist sehr einfach. Wir haben es vorher gesehen, in der Regel für Wurzel oben. Keepenv bedeutet einfach, dass die gesamte Umgebung beibehalten und weitergegeben werden soll, wie es der ausgeführte Befehl ist. Dies ist eine bequeme Verknüpfung für vertrauenswürdige Benutzer.

Die Verwendung von setenv ist ein wenig komplizierter, da es eine Kombination aus Hinzufügen, Ändern und Löschen von Umgebungsvariablen ermöglicht. Schauen wir uns ein Beispiel an.

erlauben setenv {PKG_PATH ENV = / root / .kshrc PS1 = $ DOAS_PS1} zoltan

Diese Regel erlaubt es zoltan, Befehle als root auszuführen. Die PKG_PATH-Umgebung bleibt erhalten. Die ENV-Umgebung, die auf eine Konfigurationsdatei für ksh verweist, wird auf einen von Root umgewandelt. Schließlich überschreiben wir die PS1-Einstellung, die die Eingabeaufforderung der Shell steuert. Wir geben den neuen Wert in dieser Konfigurationsdatei nicht an, sondern verwenden statt dessen den Wert in DOAS_PS1. Damit kann zoltan die Root-Eingabeaufforderung wie gewünscht anpassen.

Benutzer und Ziele

Jede Regel in doas.conf gilt für eine Person oder Gruppe, die nach Genehmigung und Optionen angegeben ist. Es gibt kein Schlüsselwort, um zwischen Benutzern und Gruppen zu unterscheiden. Stattdessen wird Syntax ähnlich chown verwendet, mit Benutzernamen selbst oder: Gruppennamen mit einem führenden Doppelpunkt. Jetzt ist eine gute Zeit für eine Erinnerung, dass Regeln immer ausgewertet werden, um mit der letzten Matching-Regel gewinnen. Spezifische Benutzerregeln werden nicht automatisch über Gruppenregeln bevorzugt, es sei denn, sie kommen später in der Datei.

In den meisten Situationen wird doas verwendet, um Befehle als root auszuführen. Dies erfordert keine zusätzliche Syntax. Allerdings können wir auch einige Regeln auf bestimmte Benutzer beschränken.

erlaube nopass zoltan als dbadmin

Diese Regel lässt zoltan die Befehle als Datenbankadministrator ohne Eingabe eines Passworts ausführen, erlaubt aber nicht, dass zoltan alles als root ausführt.

Befehle

Wir sind am Ende unserer Tour durch die doas.conf Syntax. Doas können auch eingeschränkt werden, so dass Regeln nur für bestimmte Befehle oder sogar bestimmte Befehle mit bestimmten Argumenten gelten.

erlauben nopass: operator cmd reboot

Normalerweise benötigt der Neustart root-Berechtigungen. Es wird stattdessen indirekt durch das setuid Programmabschaltung ausgeführt, dessen Ausführung auf die Operatorgruppe beschränkt ist. Die oben genannte Regel ermöglicht es diesen Benutzern, einen Neustart direkt auszuführen. Allerdings können die Operatoren nicht in der Lage sein, andere Befehle als root auszuführen oder eine Shell zu erhalten.

erlauben zoltan cmd sh args / etc / netstart

Hier erlauben wir es dem Zoltan, das Netstart-Skript zu starten, das Netzwerkschnittstellen konfiguriert. Wir geben keine Zoltan-Erlaubnis, irgendeinen Shell-Befehl auszuführen, nur das Netstart-Skript.

In diesen beiden Beispielen wurde das cmd nur mit dem Basisnamen angegeben. In diesen Fällen beschränkt sich doas nur auf Befehle im System PATH (/ bin: / sbin: / usr / bin: / usr / sbin: / usr / local / bin: / usr / local / sbin). Zoltan wird nicht in der Lage sein, eine Binärdatei in seinem Heimatverzeichnis zu installieren und PATH auf ~ / bin zu setzen, um unsere Absichten zu untergraben. Absolute Pfadnamen können auch angegeben werden, aber der Benutzer wird auch verpflichtet, sie vollständig auszutauschen.

Alle angegebenen Befehlsargumente müssen in ihrer Gesamtheit angegeben werden.

erlaube zoltan cmd ifconfig args iwm0 up
erlaube zoltan cmd ifconfig args iwm0 unten

Diese beiden Regeln erlauben es dem Zoltan, die WiFi-Schnittstelle ein- und auszuschalten, aber nicht irgendwelche anderen Parameter zu ändern.

Einige Userland-Dienstprogramme, die Informationen aus dem Kernel sammeln, stellen nur eine eingeschränkte Teilmenge von Informationen dar, wenn sie als reguläre Benutzer sind. Um die vollständigen Informationen zu sehen, muss man als root laufen. Zum Beispiel wird fstat nur minimale Informationen über Unix-Domain-Sockets drucken.

tedu Xorg 94581 16 * unix stream 0x0
tedu Xorg 94581 17 * unix stream 0x0
tedu Xorg 94581 18 * unix stream 0x0
tedu Xorg 94581 19 * unix stream 0x0
tedu Xorg 94581 20 * unix stream 0x0

Aber wenn ich wieder als Wurzel renne, sehen wir viel mehr Informationen.

tedu Xorg 94581 16 * unix stream 0xffff800000b45980 <-> 0xffff800000b3d700
tedu Xorg 94581 17 * unix stream 0xffff800000b3d880 <-> 0xffff800000b45500
tedu Xorg 94581 18 * unix stream 0xffff800000b45480 <-> 0xffff800000b45300
tedu Xorg 94581 19 * unix stream 0xffff800000b45080 <-> 0xffff800000128e80
tedu Xorg 94581 20 * unix stream 0xffff800000b60280 <-> 0xffff800000b60780

Dies ermöglicht es uns, diese Sockets mit dem Prozess am anderen Ende zu übereinstimmen.

tedu xterm 33159 3 * unix stream 0xffff800000b45300 <-> 0xffff800000b45480
tedu Xorg 94581 18 * unix stream 0xffff800000b45480 <-> 0xffff800000b45300

Diese Kernel-Adressen sind normalerweise verborgen, weil sie Informationen über das Speicherlayout des Kernels verraten, die verwendet werden können, um Exploits zu erleichtern, aber wenn wir Tedu vertrauen (und wer nicht wirklich?), Dann können wir dies mit einer einfachen config-Regel ändern.

erlauben nopass tedu cmd fstat args -u tedu

Mit fstat kann man immer die offenen Dateien der Prozesse anderer Benutzer sehen, aber wir geben hier Argumente an, um zu verhindern, dass Tedu Verbindungen zwischen Prozessen abbilden kann.

verweigern

Im Gegensatz zu all den erlaubten Regeln, die wir bisher gesehen haben, ist es auch möglich, eine Leugnungsregel zu erstellen, die die Befehlsausführung ausdrücklich verweigert. Diese Funktion ist besonders nützlich als Schutz gegen versehentliche Tippfehler von vertrauenswürdigen Operatoren. Es sollte nicht als Sicherheitsmerkmal verwendet werden, weil eine erschöpfende Blacklist anstrengend ist, um zu schaffen. Besser, um einen Regelsatz zu erstellen, der keine unbeabsichtigten Privilegien gewährt.

Genehmigung: Rad
verleugnen zoltan cmd reboot

Angenommen, dass zoltan im Gruppenrad ist, lassen wir ihn einen Befehl führen. Einfach nicht neu starten Vielleicht ist zoltan ein kleiner Auslöser glücklich und hat die Gewohnheit, in das falsche Terminal zu schreiben. Dieser Regelsatz wird Zoltan nicht wirklich daran hindern, die Maschine mit irgendwelchen Mitteln neu zu starten; Die erste Regel gewährt genügend Privileg, doas.conf zu bearbeiten und die zweite Regel zu entfernen, unter vielen anderen Möglichkeiten. Die Annahme ist, dass jeder auf dem gleichen Team ist.

Mach wie

Der doas Befehl selbst hat ein paar Optionen.

Da wir gerade mit der Syntax der Konfigurationsdatei fertig sind, kann die -C-Option zur Syntax verwendet werden, um eine neue Datei vor der Installation zu überprüfen. Es erlaubt auch die Überprüfung des Ergebnisses der Regelsatzauswertung für einen gegebenen Befehl und Argumente, ohne den Befehl auszuführen. Wenn wir mit dem fstat-Beispiel von früher fortfahren, können wir überprüfen, ob nur der Befehl mit Argumenten übereinstimmt.

$ doas -C doas.conf fstat
verweigern
$ doas -C doas.conf fstat -u tedu
erlauben nopass

Beim Schreiben von möglicherweise nicht interaktiven Skripten, die Doas enthalten, ist die Option -n hilfreich, um zukünftige Fehler zu verhindern. Nur nopass Regeln werden erfolgreich ausgeführt. Jede Regel, die ein Passwort erfordert, wird sofort fehlschlagen. Dies schließt alle Regeln mit dem persist Schlüsselwort ein, unabhängig davon, ob der Benutzer vor kurzem autorisiert hat.

Vielen Dank

Es wäre nicht möglich gewesen, doas ohne die Unterstützung von vielen anderen OpenBSD-Entwicklern zu beenden.
Wobei man wieder sieht, dass automatische Übersetzung, zumindest für technische Texte irgendwo zwischen "bringt nicht viel" und "gefährlich" liegt.
Wenn mit diesem übersetzten Text jemand eine Sicherheitsrelevanten Software konfigurieren will... Gut Nacht Marie....
Aber ich glaube das bringt uns auch nicht weiter.
 
Wobei man wieder sieht, dass automatische Übersetzung, zumindest für technische Texte irgendwo zwischen "bringt nicht viel" und "gefährlich" liegt.
Wenn mit diesem übersetzten Text jemand eine Sicherheitsrelevanten Software konfigurieren will... Gut Nacht Marie....
Aber ich glaube das bringt uns auch nicht weiter.
Ach @Rakor , es geht doch nur darum, sich einen groben Überblick zu verschaffen um es zu verstehen, und dafür reicht es allemal, es ersetzt sicherlich nicht das Lesen der Manpage, das dürfte doch jedem klar sein.;)
 
Ja, ich hätte es kurz überarbeiten sollen, habe ich auch jetzt gerade gemacht, hat keine 5 Minuten gedauert. An manchen Stellen ist die Übersetzung witzig, aber hier im Forum weiß wohl jeder, was gemeint ist. Jdenfalls bin ich dankbar dafür, das es den Google Übersetzer gibt, der oft ausreicht. In meiner OpenBSD Doku, an der ich arbeite, ist das natürlich korrigiert.
 
aber hier im Forum weiß wohl jeder, was gemeint ist.

Gerade der, der eh schon weiß, was gemeint ist, hat das Ding vorher auf Englisch gelesen und verstanden und tut sich keine automatisierten Übersetzungen an.

Solche Übersetzungen sind für absolute Sprachlaien gut, die sich einmal und nie wieder einen groben Überblick verschaffen wollen, worum es ungefähr geht. Beim regelmäßigen Einsatz im technischen Bereich würde ich den Sinn allerdings stark anzweifeln. Nimms nicht persönlich, aber wer eine Dokumentation für Andere auf Basis einer automatisierten Übersetzung erstellen will, sollte es besser gleich lassen.
 
Lieber Ralph,

bitte nimm es mir nicht übel, aber an der Stelle der Übersetzung durch den Google Trsanslator musste ich doch laut lachen :D

Viele Grüße
Holger

Lieber Holger,
warum sollte ich Dir das übel nehmen? Schließlich habe ich es ja nicht übersetzt. Egal, Ihr habt Euren Spaß gehabt und fertig! Aber es war en Fehler, die Rohübersetzung ohne Korrektur zu posten. Aber schön, das es Euch Spaß gemacht habt.:D

Viele Grüße
Ralph
 
Zurück
Oben