Es ist lange her, also fasse ich es zuerst zusammen.
In letzter Zeit sehe ich die Tatsache, dass es Menschen gibt, die den Menschen nicht kennen und machen, deshalb habe ich es ein wenig umständlich beschrieben, einschließlich Anwendungsbeispielen dazu.
Dieser Artikel entspricht fast dem Inhalt von "from sudo to doas", der in der Januar 2020-Ausgabe des Software Design Magazins veröffentlicht wurde, und nicht dem Originalmanuskript selbst. Als ich die Geschichte enthüllte, schrieb ich sie ursprünglich mit der Absicht, sie auf Qiita zu veröffentlichen, aber die Wahrheit ist, dass Software Design die Tatsache aufgegriffen hat, dass ich zu viel geschrieben habe und der Band zu einem Artikel in einer Zeitschrift wurde. .. </ small>
Der Befehl sudo ist so weit verbreitet, dass er für die Systemverwaltung in UNIX-basierten Betriebssystemen unerlässlich ist.
Ursprünglich wird der Befehl su standardmäßig unter UNIX bereitgestellt und ist auch in verschiedenen BSD- und Linux-Distributionen verfügbar. su ist ein Befehl, den der Benutzer benötigt, um vorübergehend Root-Berechtigungen zu erhalten. Bei der Ausführung wird die Shell der Root-Umgebung gestartet, aber das Root-Kennwort ist erforderlich, um Berechtigungen zu erhalten. Sie können alle Benutzerrechte erhalten, die nicht root sind, aber Sie benötigen das Passwort des Benutzers, der diese Rechte erhalten möchte. Mit anderen Worten, su benötigt das Passwort des Benutzers, der von nun an berechtigt ist, es zu verwenden.
Wenn es nur einen Server gibt und der Administrator der Benutzer ist, ist su bei der Verwendung von Berechtigungen kein Problem. Betrachten Sie nun den Fall, dass Sie mehrere Server haben und jeder ein gemeinsames Root-Passwort hat und Sie einem bestimmten Benutzer nur die Berechtigungen eines bestimmten Servers erteilen müssen. Um su zu verwenden, kann der Benutzer, wenn das Root-Passwort für alle Server gleich bleibt, Berechtigungen auf einem anderen Server erhalten. Daher müssen Maßnahmen ergriffen werden, z. B. das Root-Passwort nur für diesen Server festzulegen. Werden. Wenn Sie so etwas auf mehreren Servern festlegen, müssen Sie möglicherweise das Root-Passwort ändern oder einen anderen privilegierten Benutzer als root vorbereiten.
sudo löst das oben genannte Problem, indem Sie Ihr eigenes Passwort als Passwort verwenden, um Berechtigungen zu erhalten. Natürlich ist es ein Problem, wenn jeder Berechtigungen mit seinem eigenen Kennwort erhalten kann. Daher ist es möglich, Benutzer mit der Einstellungsdatei einzuschränken und auch die Befehle einzuschränken, die mit Berechtigungen verwendet werden können. Es enthält auch einen speziellen Befehl namens visudo zum Bearbeiten der Konfigurationsdatei.
Ich persönlich finde sudo in den folgenden drei Punkten nützlich.
Um das zweite Element ein wenig zu ergänzen, können Sie nur einen Befehl mit Berechtigungen ausführen, indem Sie ein Argument mit su angeben. Die Parameterspezifikation ist jedoch kompliziert und die Benutzerfreundlichkeit für sudo verbessert.
Befehle, die mit Berechtigungen umgehen, wie z. B. sudo, weisen häufig Schwachstellenprobleme auf. Zuletzt (Mitte Oktober 2019) wurde über die Sicherheitslücke in Sudo gesprochen. Die Sicherheitsanfälligkeit bestand darin, dass ein Benutzer mit sudo-fähigen Einstellungen Berechtigungen außerhalb der Konfigurationsgrenzen erhalten konnte.
sudo ist ein alter Befehl, der eine Geschichte von ungefähr 30 Jahren hat, und ich benutze ihn seit den frühen 90ern, aber seitdem habe ich gelegentlich Berichte über sudo-Schwachstellen gesehen. Obwohl sudo viele Verwaltungsfunktionen hat und bequem eingerichtet werden kann, gibt es viele Funktionen, die sicherlich praktisch sind, aber in der Praxis nur selten verwendet werden. Es ist sehr schwierig, das Einstellungshandbuch zu lesen und alle Funktionen zu verstehen, und ich persönlich benutze es, während ich denke "Ich brauche solche Funktionen nicht ..." [^ 1].
[^ 1]: Um ehrlich zu sein, verstehe ich nicht alle Funktionen von sudo.
Als ich diesen Bericht über Sudo-Schwachstellen sah, dachte ich: "Ist es wieder anfällig für Sudo?", Aber ich erinnerte mich, dass OpenBSD in letzter Zeit Doas als Standardbefehl hat. Wenn es meine Verwendung ist, ist die Funktion bis zu sudo völlig unnötig, deshalb habe ich diese Gelegenheit genutzt, um doas einzuführen.
Ähnlich wie bei sudo erhält doas auch Berechtigungen mit seinem eigenen Passwort. Der Unterschied besteht darin, dass die Funktionalität im Vergleich zu sudo sehr eingeschränkt ist und nur die minimale Funktionalität vorhanden ist, die Sie für erforderlich halten. Beispielsweise kann sudo mehrere Benutzer und Befehle verwalten, indem sie mithilfe von Befehlen und Benutzeraliasnamen gruppiert werden. Doas verfügt jedoch über keine praktischen Funktionen für eine solche Verwaltung. Auf den ersten Blick scheint es jedoch kein Problem mit Doas in meinem Anwendungsbereich zu geben, und ich denke, dass dies für viele Anwendungsbereiche ausreicht.
Wie oben erwähnt, ist doas einer der Befehle, die aus dem OpenBSD-Projekt stammen. OpenBSD ist ein sehr sicherheitsorientiertes Betriebssystem, und OpenSSH, eine typische Implementierung von SSH, die heute üblich ist, ist auch ein Produkt des OpenBSD-Projekts. In dieser Hinsicht kann man sagen, dass aus OpenBSD geborene Doas in Bezug auf die Sicherheit zuverlässig sind. [^ 2].
[^ 2]: Versteh mich nicht falsch, weil ich Sudo nicht vertraue
Normalerweise verwende ich FreeBSD als Hauptumgebung. Als ich dachte, dass sich doas wie erwartet bereits in Ports befinden würde, war dies in security / doas und pkg auch vorhanden. Dann installiere doas pkg.
$ sudo pkg install doas
Updating FreeBSD repository catalogue...
----- (Unterlassung) -----
New packages to be INSTALLED:
doas: 6.2
Number of packages to be installed: 1
Proceed with this action? [y/N]: y
[1/1] Installing doas-6.2...
[1/1] Extracting doas-6.2: 100%
=====
Message from doas-6.2:
--
To use doas,
/usr/local/etc/doas.conf
must be created. Refer to doas.conf(5) for further details.
----- (Folgendes wird weggelassen) -----
Nach Abschluss der Installation müssen Sie im nächsten Schritt doas einrichten. Wie Sie der Installationsmeldung entnehmen können, werden die Einstellungen in /usr/local/etc/doas.conf beschrieben. Da das Paket nicht die Dateien enthält, die die Grundlage für die Bearbeitung von doas.conf bilden, muss es von Grund auf neu festgelegt werden, dies ist jedoch nicht schwierig. Tatsächlich ist es nicht das erste Mal, dass ich Doas setze, und ich habe in der Vergangenheit Erfahrung damit, es mit OpenBSD zu setzen und zu verwenden. Zu diesem Zeitpunkt habe ich jedoch nur eine Zeile mit den Mindesteinstellungen für doas geschrieben.
In jedem Fall ist es wichtig, das Handbuch zu überprüfen, wenn Sie einen neuen Befehl einrichten. Verwenden Sie den Befehl man, um zu sehen, wie doas.conf konfiguriert wird.
$ man doas.conf
DOAS.CONF(5) FreeBSD File Formats Manual DOAS.CONF(5)
NAME
doas.conf - doas configuration file
SYNOPSIS
/usr/local/etc/doas.conf
DESCRIPTION
The doas(1) utility executes commands as other users according to the
rules in the doas.conf configuration file.
The rules have the following format:
permit|deny [options] identity [as target] [cmd command [args ...]]
Rules consist of the following parts:
permit|deny The action to be taken if this rule matches.
----- (Folgendes wird weggelassen) -----
Wie Sie sehen können, wird in doas.conf eine Regel pro Zeile beschrieben, und obwohl sie in der zweiten Hälfte beschrieben wird, fungiert '' als Escape, was eine relativ vertraute Spezifikation ist. Es gibt ein Einstellungsbeispiel in der zweiten Hälfte des Menschen, aber selbst wenn es enthalten ist, ist das Ganze kurz genug, um es zu schlagen, und Sie können sehen, dass es im Vergleich zu Sudoern, einer Einstellungsdatei von Sudo, nur sehr wenige Einstellungselemente gibt. Zum Beispiel gibt es nur vier Optionsschlüsselwörter: nopass, keepenv, verurv und persist.
Normalerweise ist jede Zeile eine Erlaubnis, gefolgt von den erforderlichen Optionen, und die Identität wird auf den Benutzernamen oder den Gruppennamen festgelegt. Um einen Gruppennamen anzugeben, fügen Sie am Anfang des Gruppennamens Folgendes hinzu: Beispiel: Rad. Wie oben erwähnt, enthält das Handbuch auch Einstellungsbeispiele. Es empfiehlt sich daher, auf diese zu verweisen.
Da doas keinen eigenen Befehl zum Bearbeiten der Einstellungsdatei wie visudo in sudo hat, bereiten Sie /usr/local/etc/doas.conf mit einem vertrauten Editor wie vi, vim, nano vor. Das folgende Beispiel enthält eine einzelne Zeile der Datei doas.conf.
$ sudo vi /usr/local/etc/doas.conf
----- (doas.Bearbeitung conf) -----
$ ls -l /usr/local/etc/doas.conf
-rw-r--r-- 1 root wheel 64 Oct 21 18:11 /usr/local/etc/doas.conf
$ cat /usr/local/etc/doas.conf
permit nopass minmin
$
Wie in diesem Beispiel sollten die Berechtigungen für doas.conf auf 644 (im Besitz von root) oder 640 oder 600 (je nach Bedarf) festgelegt werden. Da der Autor normalerweise minmin als Benutzernamen verwendet, wird dies hier als Beispiel gezeigt.
In den Einstellungen wird die Option nopass zu den Optionen hinzugefügt, sodass jeder Befehl mit Berechtigungen ohne Kennwort ausgeführt werden kann. ** Ich empfehle dies nicht, da die Gefahr besteht, dass die Option nopass ohne Kennwort festgelegt wird **. Dies ist nur meine persönliche Servereinstellung, und andere Server verwenden die Option nopass oder nicht.
Wie ich am Anfang geschrieben habe, hat sudo die Funktion, die Passworteingabe für eine Weile (standardmäßig 15 Minuten) wegzulassen, wenn sudo nach seiner Ausführung wiederholt verwendet wird, und doas hat auch eine Persist-Option, die eine ähnliche Funktion bietet. Es scheint vorbereitet zu sein, aber es wird angegeben, dass es nur mit OpenBSD verwendet werden kann.
persist After the user successfully authenticates, do not
ask for a password again for some time. Works on
OpenBSD only, persist is not available on Linux or
FreeBSD.
In sudo überprüft visudo die Syntax von sudores nach der Bearbeitung, warnt vor einem Fehler und kann ohne Beenden erneut bearbeiten. In doas.conf wird jedoch möglicherweise ein gewöhnlicher Editor verwendet, der zum Zeitpunkt der Bearbeitung festgelegt wird Es können keine Fehler bestätigt werden. Stattdessen kann doas selbst die Konfigurationsdatei mit der Option -C überprüfen.
$ doas -C /usr/local/etc/doas.conf
$
Wenn ein Fehler auftritt, wird eine Fehlermeldung angezeigt, sodass Sie sehen können, dass doas.conf hier problemlos beschrieben werden kann.
Wenn Sie in doas.conf einen Fehler machen, besteht das Risiko, dass doas nicht ausgeführt werden kann. Wenn Sie also eine vorhandene doas.conf bearbeiten, ist es sicherer, die folgenden Schritte auszuführen.
$ cp /usr/local/etc/doas.conf /tmp ← Einmal/doas in tmp.Kopieren Sie conf
$ vi /tmp/doas.conf ← doas.Bearbeitung conf
<Nehmen Sie die erforderlichen Änderungen vor>
$ doas -C /tmp/doas.conf ← Bestätigung der Einstellungen nach der Bearbeitung
$ doas install -m 644 /tmp/doas.conf /usr/local/etc ← doas.Update conf
$
Sie können doas-Optionen mit man doas nachschlagen, aber ich werde sie kurz auflisten.
--- a: Geben Sie die in /etc/login.conf beschriebene doas-Authentifizierungsmethode an --- C Dateiname: Überprüfen Sie die Syntax mit der angegebenen Datei als Doas-Einstellungsdatei --- n: Geben Sie für die nicht interaktive Verwendung an (z. B. bei Verwendung von doas auf einem Remote-Server über ssh). --- s: Starten Sie die Shell des Benutzers --- u Benutzername: Ruft die Berechtigungen des angegebenen Benutzers ab (Standard ist root). ---: Interpretiere das, was danach angegeben wird, als Ausführungsbefehl und Argument
Der Befehl id ist der beste Weg, um festzustellen, ob doas funktioniert.
$ doas id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
$
Wie Sie sehen können, ist die UID 0, dh Sie können den Befehl id mit Root-Berechtigungen ausführen und haben die Berechtigung.
Persönlich ist das Wichtigste, wie mit der Umgebungsvariablen PATH umgegangen wird, wenn doas verwendet wird. Wenn beispielsweise ~ / bin in Ihrem Home-Verzeichnis Befehle für den persönlichen Gebrauch enthält und Sie diese für die Systemadministration verwenden möchten, können diese Befehle einfach nicht verwendet werden, wenn sich der PATH ändert. Selbst wenn Sie mit doas zu Privilegien wechseln, ist es praktisch, wenn Sie den normalerweise festgelegten Pfad übernehmen können.
Lassen Sie uns zunächst mit dem Befehl env überprüfen, was mit dem PATH passiert.
$ doas env | fgrep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$
In der doas-Umgebung ist dies standardmäßig der PFAD, und Sie können sehen, dass Ihr PFAD nicht vererbt wird. Um den persönlichen Pfad zu erben, schien es mir, dass ich die Option keepenv auf einen Blick verwenden sollte, also habe ich sie festgelegt und ausprobiert.
$ cat /usr/local/etc/doas.conf
permit nopass keepenv minmin
$ doas env | fgrep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$
Es gibt keine Änderung in PATH. Schauen Sie sich also keepenv in doas.conf genauer an.
keepenv The user's environment is maintained. The default
is to reset the environment, except for the
variables DISPLAY and TERM.
----- (Unterlassung) -----
Note: The target user's PATH variable can be set at
compile time by adjusting the GLOBAL_PATH variable
in doas's Makefile. By default, the target user's
path will be set to
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:"
Wie Sie im letzten Abschnitt "Hinweis:" sehen können, wird der Pfad für privilegierte Benutzer in doas auf den zum Zeitpunkt der Kompilierung angegebenen Pfad festgelegt.
** Im Allgemeinen ist es ein Sicherheitsrisiko, die Umgebungsvariable PATH so zu erben, wie sie ist **. Der Standardpfad beim Ausführen von doas lautet also wie folgt, aber es ist in Ordnung, dass der Administrator bei Bedarf seinen PFAD übernimmt. Nach der Überprüfung stellte ich fest, dass ich es explizit mit der Option setenv angeben sollte, um den PATH des Benutzers zu erben.
$ cat /usr/local/etc/doas.conf
permit nopass keepenv setenv { PATH } minmin
$ doas env | fgrep PATH
PATH=/home/minmin/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin
$
Immerhin wurde doas.conf auf meinem persönlichen Server wie folgt mit zwei Zeilen eingerichtet.
$ cat /usr/local/etc/doas.conf
permit nopass setenv { PATH } minmin
permit nopass keepenv root
$
Selbst wenn Sie ein Root-Benutzer sind und Doas verwenden und keine Einstellung vorhanden ist, wird die Ausführung von Doas abgelehnt. Die zweite Zeile ist daher eine Einstellung, um dies zu vermeiden.
In der Beschreibung von man kann die HOME-Variable des Benutzers gelesen werden, damit sie von keepenv geerbt werden kann. Als ich es jedoch versuchte, schien dies nicht der Fall zu sein. Wenn Sie die HOME-Variable erben möchten, müssen Sie sie explizit mit setenv angeben. In meinem Fall spielt es keine Rolle, da ich die Desktop-Umgebung nicht mit FreeBSD verwende. Bei Verwendung der Desktop-Umgebung scheint die Anwendung jedoch abstürzen zu können, wenn die Umgebungsvariablen nicht ordnungsgemäß vererbt werden.
Wenn Sie doas ausführen, wird es in /var/log/auth.log für FreeBSD aufgezeichnet (dasselbe gilt für sudo). Sie benötigen auch Berechtigungen, um auth.log anzuzeigen. Verwenden Sie daher doas, um dies zu überprüfen.
$ doas id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
$ doas tail -2 /var/log/auth.log
Oct 28 23:11:17 fbsdsvr doas: minmin ran command id as root from /home/minmin
Oct 28 23:11:37 fbsdsvr doas: minmin ran command tail -2 /var/log/auth.log as root from /home/minmin
$
Beachten Sie, dass die Beschränkung des Endes auf nur -2 und zwei Zeilen nur die Anzeige zusätzlicher Elemente verhindert, um dieses Beispiel zu erstellen, und dass es keine weitere Bedeutung gibt.
Ich habe festgestellt, dass doas unter Linux verwendet werden kann, da die persist-Option des im vorherigen Abschnitt angegebenen Handbuchs eine Linux-Zeichenfolge enthält, und habe sie tatsächlich in Linux eingeführt. Es gibt verschiedene Distributionen von Linux, aber hier versuche ich es unter Debian / Ubuntu und CentOS.
Da doas derzeit kein Befehl wie sudo ist, gibt es meines Erachtens keine Pakete für Linux. Um doas zu installieren, müssen Sie die Quelle vorbereiten und die Kompilierungs- und Installationsarbeiten durchführen.
Die Quelle ist im OpenBSD-Quellbaum enthalten, da doas selbst Teil von OpenBSD ist. Selbst wenn Sie nur den doas-Teil aus der OpenBSD-Quelle mitbringen, sind einige Dinge nicht ausreichend, und das Kompilieren unter anderen Betriebssystemen ist nicht reibungslos. Daher ist auf Github ein Paket auf Quellenebene verfügbar, damit es unter anderen Betriebssystemen wie Linux kompiliert werden kann.
https://github.com/slicer69/doas/
Extrahieren Sie diese Quelle zunächst lokal mit dem Git-Klon.
$ git clone https://github.com/slicer69/doas.git
----- (Unterlassung) -----
$ cd doas
$ ls -F
LICENSE README.md doas.1 doas.conf.5 env.c
Makefile compat/ doas.c doas.h parse.y
$
Wie Sie aus der Liste der Dateien sehen können, ist doas in C geschrieben.
Laut README.md können Sie unter Linux mit make kompilieren und mit make install installieren, sodass es anscheinend nichts Schwieriges gibt. Kompilieren wir es also sofort. Ich habe Folgendes unter Debian versucht, aber ich habe bestätigt, dass Ubuntu genau das Gleiche kann.
Um C-Programme mit Debian zu kompilieren, benötigen Sie das Build-Essential-Paket, bei dem es sich um die Entwicklungsumgebung handelt. Installieren Sie also zuerst Build-Essential.
$ sudo apt update
----- (Unterlassung) -----
$ sudo apt -y install build-essential
----- (Unterlassung) -----
$
Wenn Sie die Entwicklungsumgebung bereits vorbereitet haben, können Sie diese Arbeit natürlich weglassen.
Lassen Sie es uns tatsächlich kompilieren.
$ make
cc -Wall -O2 -DUSE_PAM -DDOAS_CONF=\"/usr/local/etc/doas.conf\" -D_GNU_SOURCE -include compat/compat.h -Icompat -c -o doas.o doas.c
doas.c:48:31: fatal error: security/pam_appl.h:Es gibt keine solche Datei oder kein solches Verzeichnis
#include <security/pam_appl.h>
^
compilation terminated.
<Eingebaut>:Ziel'doas.o'Fehler mit dem Rezept
make: *** [doas.o]Fehler 1
$
Wenn die Header-Datei pam_appl.h nicht gefunden wird, tritt ein Fehler auf und die Kompilierung wird gestoppt. Wenn Sie nachschlagen, benötigen Sie pam_appl.h, um ein Programm zu erstellen, das PAM verwendet. Tatsächlich gab README.md an, dass libpam0g-dev erforderlich ist (README.md muss sorgfältig gelesen werden ^^;).
$ sudo apt -y install libpam0g-dev
Lassen Sie uns einen zweiten Blick darauf werfen und erneut versuchen, zu kompilieren.
$ make
cc -Wall -O2 -DUSE_PAM -DDOAS_CONF=\"/usr/local/etc/doas.conf\" -D_GNU_SOURCE -include compat/compat.h -Icompat -c -o doas.o doas.c
cc -Wall -O2 -DUSE_PAM -DDOAS_CONF=\"/usr/local/etc/doas.conf\" -D_GNU_SOURCE -include compat/compat.h -Icompat -c -o env.o env.c
cc -Wall -O2 -DUSE_PAM -DDOAS_CONF=\"/usr/local/etc/doas.conf\" -D_GNU_SOURCE -include compat/compat.h -Icompat -c -o compat/execvpe.o compat/execvpe.c
compat/execvpe.c: In function ‘execvpe’:
compat/execvpe.c:61:5: warning: nonnull argument ‘name’ compared to NULL [-Wnonnull-compare]
if ( (! name) || (*name == '\0') ){
^
cc -Wall -O2 -DUSE_PAM -DDOAS_CONF=\"/usr/local/etc/doas.conf\" -D_GNU_SOURCE -include compat/compat.h -Icompat -c -o compat/reallocarray.o compat/reallocarray.c
yacc parse.y
make: yacc:Befehl nicht gefunden
Makefile:54:Ziel'y.tab.o'Fehler mit dem Rezept
make: *** [y.tab.o]Fehler 127
$
Ohne den Befehl yacc bekam ich einen Fehler und die Kompilierung wurde beendet. Ich bemerkte, dass build-essential yacc nicht enthielt (das ist richtig). Mit Debian können Sie ein Paket aus mehreren yacc-Implementierungen auswählen. Hier installieren wir jedoch die Berkeley-Version von yacc byacc und kompilieren sie erneut. Selbst wenn Sie Bison anstelle von Byacc installieren, können Sie dennoch in Debian / Ubuntu kompilieren.
$ sudo apt -y install byacc
----- (Unterlassung) -----
$ make
yacc parse.y
cc -include compat/compat.h -Icompat -Wall -O2 -DUSE_PAM -DDOAS_CONF=\"/usr/local/etc/doas.conf\" -D_GNU_SOURCE -c y.tab.c
----- (Unterlassung) -----
cc -o doas doas.o env.o compat/execvpe.o compat/reallocarray.o y.tab.o compat/closefrom.o compat/errc.o compat/getprogname.o compat/setprogname.o compat/strlcat.o compat/strlcpy.o compat/strtonum.o compat/verrc.o -lpam -lpam_misc
$
Nachdem die Kompilierung abgeschlossen ist, ist es Zeit für die Installation.
$ sudo make install
mkdir -p /usr/local/bin
cp doas /usr/local/bin/
chmod 4755 /usr/local/bin/doas
mkdir -p /usr/local/man/man1
cp doas.1 /usr/local/man/man1/
mkdir -p /usr/local/man/man5
cp doas.conf.5 /usr/local/man/man5/
$
Wie Sie dem ausgeführten Befehl entnehmen können, werden die tatsächlich von make install installierten Dateien in der folgenden Tabelle angezeigt.
| Datei | Dateiinhalt |
|---|---|
| /usr/local/bin/doas | Programmkörper von Doas |
| /usr/local/man/man1/doas.1 | doas befiehlt sich man man file |
| /usr/local/man/man5/doas.conf.5 | doas.conf man Datei |
Mit dieser Anzahl von Dateien ist es nicht schwierig, auch nicht gepackte Programme zu verwalten. Wenn Sie doas in Zukunft deinstallieren müssen, löschen Sie einfach diese drei Dateien und die doas-Konfigurationsdatei /usr/local/etc/doas.conf.
Bereiten Sie nach der Installation von doas doas.conf vor, aber hier habe ich das gleiche Set vorbereitet, das in FreeBSD in / usr / local / usw. festgelegt wurde.
Im Fall von Debian wird die Ausführung von doas in /var/log/auth.log wie in FreeBSD aufgezeichnet, aber wenn Sie Optionen für den auszuführenden Befehl angeben, wird diese aufgrund der Optionsanalysebibliothek explizit vom Befehl getrennt. Es scheint notwendig zu sein, "-" anzugeben.
$ doas id
uid=0(root) gid=0(root) groups=0(root)
$ doas tail -2 /var/log/auth.log
doas: invalid option -- '2'← '2' wird als Option von doas selbst behandelt und es tritt ein Fehler auf
usage: doas [-ns] [-a style] [-C config] [-u user] command [args]
$ doas -- tail -2 /var/log/auth.log
Oct 30 23:50:25 idmdemo0 doas: minmin ran command id as root from /home/minmin
Oct 30 23:50:35 idmdemo0 doas: minmin ran command tail -2 /var/log/auth.log as root from /home/minmin
Ich habe auch versucht, doas unter CentOS zu kompilieren und zu installieren.
Wenn Sie die PAM-Header-Datei und yacc nicht vorbereiten, tritt das gleiche Problem wie bei Debian auf. Daher habe ich es mit gcc installiert und für die C-Kompilierung erforderlich gemacht. Die PAM-Entwicklungsumgebung verwendet das pam-devel-Paket und yacc das byacc-Paket.
$ sudo yum install gcc make pam-devel byacc
----- (Unterlassung) -----
$ make
cc -Wall -O2 -DUSE_PAM -DDOAS_CONF=\"/usr/local/etc/doas.conf\" -D_GNU_SOURCE -include compat/compat.h -Icompat -c -o doas.o doas.c
----- (Unterlassung) -----
cc -o doas doas.o env.o compat/execvpe.o compat/reallocarray.o y.tab.o compat/closefrom.o compat/errc.o compat/getprogname.o compat/setprogname.o compat/strlcat.o compat/strlcpy.o compat/strtonum.o compat/verrc.o -lpam -lpam_misc
$ sudo make install
----- (Unterlassung) -----
$
Es gibt keinen Unterschied zwischen den installierten Dateien und Debian.
Im Fall von CentOS muss byacc nicht neu installiert werden, wenn Bison bereits installiert ist, und Sie können kompilieren, indem Sie make mit make YACC = 'bison -y' starten.
Stellen Sie doas.conf wie im bereits eingeführten Betriebssystem ein und überprüfen Sie die Funktion von doas mit dem Befehl id. Im Fall von CentOS lautet der Ausführungsdatensatz von doas / var / log / Secure.
$ doas id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$ doas -- tail -2 /var/log/secure
Oct 30 23:56:56 centos0 doas: minmin ran command id as root from /home/minmin
Oct 30 23:57:15 centos0 doas: minmin ran command tail -2 /var/log/secure as root from /home/minmin
Da die Quelle von Doas lokal erweitert wurde, dachte ich über diese Zeit nach und verglich einfach die Skalierung der Quelle mit Sudo anhand der Anzahl der Zeilen.
sudo wird zum Zeitpunkt des Schreibens dieses Artikels mit dem neuesten sudo-1.8.28p1.tar.gz gezählt.
$ tar xf sudo-1.8.28p1.tar.gz
$ cd sudo-1.8.28p1
$ ls -F
ABOUT-NLS config.h.in ltmain.sh
ChangeLog config.sub m4/
INSTALL configure* mkdep.pl*
INSTALL.configure configure.ac mkinstalldirs*
MANIFEST doc/ mkpkg*
Makefile.in examples/ pathnames.h.in
NEWS include/ plugins/
README indent.pro po/
README.LDAP init.d/ pp*
aclocal.m4 install-sh* src/
autogen.sh* lib/ sudo.pp
config.guess log2cl.pl*
$
Da sudo neben dem Hauptteil von sudo viele Bibliotheksdateien enthält, habe ich die C-Quelldateien (* .c) und Header-Dateien (* .h) im Verzeichnis src gezählt. [^ 3]
[^ 3]: Ich habe nicht bestätigt, ob die Quelle des Kernteils von sudo tatsächlich nur dieser Bereich ist.
$ find src -type f -name '*.[ch]' | xargs wc -l
76 src/preload.c
735 src/exec_monitor.c
----- (Unterlassung) -----
113 src/sudo_exec.h
197 src/get_pty.c
12612 total
$
Sie können sehen, dass es ungefähr 12600 Zeilen gibt. Übrigens, als ich alle Dateien gezählt habe, die *. [Ch] im Quellpaket entsprechen, gab es mehr als 100.000 Zeilen, und ich war ehrlich gesagt sehr überrascht.
Auf der anderen Seite hat doas ungefähr 1200 Zeilen, wie unten gezeigt, was im Vergleich zu sudo sehr klein ist.
$ wc *.[chy]
564 1716 13080 doas.c
65 238 1673 doas.h
230 693 4951 env.c
343 1044 6831 parse.y
1202 3691 26535 total
$
Die für die Portierung auf ein Nicht-OpenBSD-Betriebssystem erforderlichen Bibliotheken befinden sich im kompatiblen Verzeichnis. Selbst wenn Sie alle zählen, umfasst das doas-Quellpaket etwa 3000 Zeilen.
Je kleiner die Quelle, desto besser, aber je größer die Quelle, desto höher ist das Risiko, Fehler einzuschließen.
In meinem Fall verwendet sudo häufig die Optionen -u und -s, aber doas ermöglicht es ihnen auch, dieselbe Funktionalität mit denselben Optionsspezifikationen zu verwenden. Mit anderen Worten, sudo ist nicht erforderlich, wenn doas in meinem Anwendungsbereich vorhanden sind. Daher habe ich sudo in der FreeBSD-Umgebung vom System deinstalliert.
Da jedoch einige meiner eigenen Shell-Skripte sudo verwenden, setze ich sudo als symbolischen Link zu doas, einschließlich der sofortigen Unterstützung, bis es neu geschrieben wird.
$ doas ln -s doas /usr/local/bin/sudo
$ ls -l /usr/local/bin/sudo
lrwxr-xr-x 1 root wheel 4 Oct 22 10:46 /usr/local/bin/sudo -> doas
$ ls -lL /usr/local/bin/sudo
-rwsr-xr-x 1 root wheel 28800 Oct 4 05:20 /usr/local/bin/sudo
$sudo id ← Die Substanz von sudo von hier ist doas
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
$ sudo -V ← sudo ist-Option zum Anzeigen der Version in V, jedoch nicht in doas
doas: illegal option -- V
usage: doas [-ns] [-a style] [-C config] [-u user] command [args]
$
Im Fall von Linux bauen einige Linux-Distributionen das System möglicherweise unter der Annahme auf, dass es sudo gibt. Wenn Sie also sudo aus dem System entfernen, ist doas nicht genau dasselbe wie sudo. Lassen Sie es uns tun, nachdem wir verstanden haben, dass es kein Problem gibt, und beurteilen, dass es kein Problem gibt. Es ist nicht erforderlich, Sudo zum Entfernen zu zwingen.
Selbst wenn in sudo eine Sicherheitslücke entdeckt wird, besteht aufgrund der Art des Befehls kein Risiko, aus der Ferne angegriffen zu werden. Sie müssen sich nicht beeilen, um Maßnahmen zu ergreifen, insbesondere wenn der Server nur von Ihnen oder einer vertrauenswürdigen Person verwendet wird. In diesem Sinne ist es möglicherweise nicht erforderlich, auf einem privaten Server zu doas zu wechseln. Wenn Sie jedoch dieselbe Funktion verwenden möchten, sollten Sie eine einfache auswählen. Aus diesem Grund denke ich, dass es die richtige Antwort war, diesmal Doas einzuführen.