Cela fait longtemps, alors je vais d'abord le résumer.
Récemment, je vois le fait qu'il y a des gens qui ne connaissent pas l'homme et ne font pas, donc je l'ai décrit un petit rond-point, y compris des exemples d'utilisation autour de cela.
Cet article est presque le même que le contenu de "from sudo to doas" publié dans le numéro de janvier 2020 du magazine Software Design, plutôt que le manuscrit original lui-même. Quand j'ai révélé l'histoire, je l'ai initialement écrite avec l'intention de la publier sur Qiita, mais la vérité est que Software Design a pris conscience du fait que j'en ai trop écrit et que le volume est devenu un article dans un magazine. .. </ petit>
La commande sudo est si répandue qu'elle est essentielle pour la gestion du système dans les systèmes d'exploitation UNIX.
À l'origine, la commande su est fournie en standard sous UNIX, et elle est également disponible dans diverses distributions BSD et Linux. su est une commande dont l'utilisateur a besoin pour obtenir temporairement les privilèges root, et lorsqu'elle est exécutée, le shell de l'environnement root est démarré, mais le mot de passe root est requis pour obtenir les privilèges. Vous pouvez obtenir tous les droits d'utilisateur qui ne sont pas root, mais vous aurez besoin du mot de passe de l'utilisateur qui souhaite obtenir ces droits. En d'autres termes, su requiert le mot de passe de l'utilisateur habilité à l'utiliser à partir de maintenant.
S'il n'y a qu'un seul serveur et que l'administrateur est toujours l'utilisateur, su convient lors de l'utilisation des privilèges. Considérez maintenant le cas où vous avez plusieurs serveurs et chacun a un mot de passe root commun, et vous devez donner à un utilisateur particulier les privilèges d'un serveur particulier uniquement. Pour utiliser su, si le mot de passe root reste commun à tous les serveurs, l'utilisateur pourra obtenir des privilèges sur un autre serveur, il est donc nécessaire de prendre des mesures telles que la définition du mot de passe root pour ce serveur uniquement. Devenir. Si vous définissez ceci sur plusieurs serveurs, vous devrez éventuellement changer le mot de passe root ou préparer un utilisateur privilégié autre que root.
sudo résout le problème ci-dessus en utilisant votre propre mot de passe comme mot de passe requis pour obtenir des privilèges. Bien sûr, c'est un problème si tout le monde peut obtenir des privilèges avec son propre mot de passe, il est donc possible de limiter les utilisateurs avec le fichier de paramètres et également de limiter les commandes qui peuvent être utilisées avec des privilèges. Il est également livré avec une commande dédiée appelée visudo pour éditer le fichier de configuration.
Je trouve personnellement sudo utile dans les trois points suivants.
Pour compléter un peu le deuxième élément, vous ne pouvez exécuter qu'une seule commande avec des privilèges en spécifiant un argument avec su, mais la spécification du paramètre est compliquée et la convivialité est améliorée en sudo.
Les commandes qui gèrent les privilèges, comme sudo, ont tendance à avoir des problèmes de vulnérabilité. Plus récemment (mi-octobre 2019), la vulnérabilité sudo a été évoquée. La vulnérabilité était qu'un utilisateur avec des paramètres activés pour sudo pouvait obtenir des privilèges au-delà des limites de configuration.
sudo est une ancienne commande qui a une histoire d'environ 30 ans, et je l'utilise depuis le début des années 90, mais depuis lors, j'ai vu des rapports de vulnérabilités sudo de temps en temps. Bien que sudo dispose de nombreuses fonctions de gestion et puisse être configuré de manière pratique, il existe de nombreuses fonctions qui sont certainement pratiques mais rarement utilisées dans la pratique. Il est très difficile de lire le manuel de réglage et de comprendre toutes les fonctions, et je l'utilise personnellement en me disant "je n'ai pas besoin de telles fonctions ..." [^ 1].
[^ 1]: Pour être honnête, je ne comprends pas toutes les fonctions de sudo.
Quand j'ai vu ce rapport de vulnérabilités sudo, je me suis dit: "Est-il à nouveau vulnérable à sudo?", Mais je me suis souvenu que le récent OpenBSD avait doas comme commande standard. Si c'est mon usage, la fonction jusqu'à sudo est complètement inutile, j'ai donc profité de l'occasion pour présenter doas.
Semblable à sudo, doas obtient également des privilèges en utilisant son propre mot de passe. La différence est que ses fonctionnalités sont très limitées par rapport à sudo, et c'est la fonctionnalité minimale dont vous pourriez avoir besoin. Par exemple, sudo peut gérer plusieurs utilisateurs et commandes en les regroupant à l'aide de commandes et d'alias d'utilisateurs, mais doas n'a pas de fonctions pratiques pour une telle gestion. Cependant, en un coup d'œil, il semble qu'il n'y ait pas de problème avec les doas dans ma gamme d'utilisation, et je pense que cela suffit pour de nombreuses utilisations.
Comme mentionné ci-dessus, doas est l'une des commandes issues du projet OpenBSD. OpenBSD est un système d'exploitation très axé sur la sécurité, et OpenSSH, une implémentation typique de SSH qui est maintenant courante, est également un produit du projet OpenBSD. À cet égard, les doas nés d'OpenBSD peuvent être considérés comme fiables en termes de sécurité. [^ 2].
[^ 2]: Ne vous méprenez pas car je ne fais pas confiance à sudo
J'utilise généralement FreeBSD comme environnement principal, donc quand je pensais que les doas seraient déjà dans les ports, comme prévu, c'était dans security / doas et pkg existait également. Ensuite, installez doas pkg.
$ sudo pkg install doas
Updating FreeBSD repository catalogue...
----- (Omission) -----
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.
----- (Ce qui suit est omis) -----
Une fois l'installation terminée, l'étape suivante consiste à configurer doas. Comme vous pouvez le voir dans le message d'installation, les paramètres sont décrits dans /usr/local/etc/doas.conf. Le package ne fournit pas les fichiers qui serviront de base à l'édition de doas.conf, vous devez donc le configurer à partir de zéro, mais ce n'est pas difficile. En fait, ce n'est pas la première fois pour moi de définir des doas, et j'ai une expérience de la configuration et de son utilisation avec OpenBSD dans le passé. Cependant, à ce moment-là, je n'ai écrit qu'une seule ligne des paramètres minimum pour les doas.
Dans tous les cas, il est important de consulter le manuel lors de la configuration d'une nouvelle commande. Utilisez la commande man pour voir comment configurer doas.conf.
$ 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.
----- (Ce qui suit est omis) -----
Comme vous pouvez le voir, dans doas.conf, une règle est décrite par ligne, et bien qu'elle soit décrite dans la seconde moitié, «\» agit comme un échappement, ce qui est une spécification relativement familière. Il y a un exemple de réglage dans la seconde moitié de man, mais même s'il est inclus, le tout est assez court pour battre, et vous pouvez voir qu'il y a très peu d'éléments de réglage par rapport à sudoers qui est un fichier de réglage de sudo. Par exemple, il n'y a que quatre mots-clés d'options: nopass, keepenv, sentenv et persistent.
Normalement, chaque ligne est un permis suivi des options requises, et l'identité est définie sur le nom d'utilisateur ou le nom du groupe. Pour spécifier un nom de groupe, ajoutez: au début du nom du groupe, tel que: roue. Comme mentionné ci-dessus, le manuel contient également des exemples de réglage, c'est donc une bonne idée de s'y référer.
Puisque doas n'a pas de commande dédiée pour éditer le fichier de configuration comme visudo dans sudo, préparez /usr/local/etc/doas.conf avec un éditeur familier tel que vi, vim, nano. L'exemple suivant fournit une seule ligne de doas.conf.
$ sudo vi /usr/local/etc/doas.conf
----- (doas.Modification de la 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
$
Comme dans cet exemple, les autorisations doas.conf doivent être définies sur 644, appartenant à root, ou 640 ou 600 selon les besoins. Étant donné que l'auteur utilise généralement minmin pour le nom d'utilisateur, il est présenté ici à titre d'exemple.
Dans les paramètres, l'option nopass est ajoutée aux options afin que toute commande puisse être exécutée avec des privilèges sans mot de passe. ** Je ne recommande pas cela car il y a un risque de paramétrage sans mot de passe avec l'option nopass **. Ce n'est que mon paramètre de serveur personnel et d'autres serveurs utilisent l'option nopass ou non.
Comme je l'ai écrit au début, sudo a une fonction pour omettre l'entrée de mot de passe pendant un certain temps (15 minutes par défaut) lors de l'utilisation répétée de sudo une fois qu'il est exécuté, et doas a également une option persist qui fournit une fonction similaire. Il semble qu'il soit préparé, mais il est précisé qu'il ne peut être utilisé qu'avec OpenBSD.
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.
Dans sudo, visudo vérifie la syntaxe des sudores après l'édition, avertit qu'il y a une erreur et peut éditer à nouveau sans quitter, mais dans doas.conf, il peut utiliser un éditeur ordinaire et il est défini au moment de cette édition Vous ne pouvez pas confirmer l'erreur. Au lieu de cela, doas lui-même a la possibilité de vérifier le fichier de configuration avec l'option -C.
$ doas -C /usr/local/etc/doas.conf
$
S'il y a une erreur, un message d'erreur sera affiché, vous pouvez donc voir que doas.conf peut être décrit sans aucun problème ici.
Si vous faites une erreur dans doas.conf, il y a un risque que doas ne puisse pas être exécuté, donc si vous éditez un doas.conf existant, il est plus sûr de suivre les étapes ci-dessous.
$ cp /usr/local/etc/doas.conf /tmp ← Une fois/doas en tmp.Copier la conf
$ vi /tmp/doas.conf ← doas.Modification de la conf
<Apportez les modifications nécessaires>
$ doas -C /tmp/doas.conf ← Confirmation des paramètres après modification
$ doas install -m 644 /tmp/doas.conf /usr/local/etc ← doas.Mettre à jour la conf
$
Vous pouvez rechercher les options doas avec man doas, mais je vais les énumérer brièvement.
--- a: Spécifiez la méthode d'authentification doas décrite dans /etc/login.conf --- C Nom du fichier: vérifiez la syntaxe avec le fichier spécifié comme fichier de configuration doas --- n: Spécifiez pour une utilisation non interactive (comme lors de l'utilisation de doas sur un serveur distant via ssh). --- s: lance le shell de l'utilisateur --- u Nom d'utilisateur: Obtenez les privilèges de l'utilisateur spécifié (la valeur par défaut est root) ---: interpréter ce qui est spécifié après cela comme une commande d'exécution et un argument
La commande id est le meilleur moyen de voir si doas fonctionne.
$ doas id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
$
Comme vous pouvez le voir, l'uid est 0, c'est-à-dire que vous pouvez exécuter la commande id avec les privilèges root et vous avez le privilège.
Personnellement, le plus important est de savoir comment gérer la variable d'environnement PATH lors de l'utilisation de doas. Par exemple, si ~ / bin dans votre répertoire personnel contient des commandes pour un usage personnel et que vous souhaitez utiliser la même chose pour le travail d'administration système, ces commandes ne peuvent tout simplement pas être utilisées si le PATH change. Même lorsque vous passez au privilège avec doas, il est pratique que vous puissiez reprendre le PATH que vous avez normalement défini.
Tout d'abord, vérifions ce qui arrive au PATH avec la commande env.
$ doas env | fgrep PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$
Par défaut, dans l'environnement doas, il s'agit du PATH, et vous pouvez voir que votre PATH n'est pas hérité. Dans le but d'hériter du PATH personnel, il me semblait que je devais utiliser l'option keepenv d'un coup d'œil, alors je l'ai définie et l'ai essayée.
$ 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
$
Il n'y a pas de changement dans PATH. Jetez donc un œil à keepenv dans doas.conf.
keepenv The user's environment is maintained. The default
is to reset the environment, except for the
variables DISPLAY and TERM.
----- (Omission) -----
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:"
Comme vous pouvez le voir dans la dernière section Note:, le PATH pour les utilisateurs privilégiés dans doas est défini sur celui spécifié au moment de la compilation.
** En général, il existe un risque de sécurité en héritant de la variable d'environnement PATH telle quelle **. Ainsi, le PATH par défaut lorsque vous exécutez doas est comme ceci, mais l'administrateur peut prendre en charge son PATH si nécessaire. Après vérification, j'ai trouvé que je devais le spécifier explicitement avec l'option setenv pour hériter du PATH de l'utilisateur.
$ 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
$
Après tout, doas.conf sur mon serveur personnel a été configuré avec deux lignes comme suit.
$ cat /usr/local/etc/doas.conf
permit nopass setenv { PATH } minmin
permit nopass keepenv root
$
Même si vous êtes un utilisateur root, lorsque vous utilisez doas, s'il n'y a pas de paramètre, l'exécution de doas sera refusée, donc la deuxième ligne est un paramètre pour l'éviter.
Dans la description de man, la variable HOME de l'utilisateur peut être lue afin qu'elle puisse être héritée par keepenv, mais quand je l'ai essayé, il semble que ce ne soit pas le cas, et si vous voulez hériter de la variable HOME, vous devez la spécifier explicitement avec setenv. Dans mon cas, cela n'a pas d'importance car je n'utilise pas l'environnement de bureau avec FreeBSD, mais lors de l'utilisation de l'environnement de bureau, il semble que l'application puisse planter si les variables d'environnement ne sont pas héritées correctement.
Lorsque vous exécutez doas, il sera enregistré dans /var/log/auth.log pour FreeBSD (idem pour sudo). Vous avez également besoin de privilèges pour voir auth.log, utilisez donc doas pour vérifier.
$ 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
$
Notez que limiter la queue à seulement -2 et deux lignes n'empêche que l'affichage d'éléments supplémentaires pour faire cet échantillon, et il n'y a pas d'autre signification.
J'ai remarqué que doas peut être utilisé sous Linux car il y a une chaîne de caractères Linux dans l'option persist du manuel cité dans la section précédente, et je l'ai en fait présenté à Linux. Il existe différentes distributions de Linux, mais ici je suis en train de l'essayer sur Debian / Ubuntu et CentOS.
Puisque doas n'est pas une commande connue de tout le monde pour le moment comme sudo, il n'y a pas de paquet pour Linux à ma connaissance. Pour installer doas, vous devez préparer la source et effectuer le travail de compilation et d'installation.
La source est incluse dans l'arborescence des sources d'OpenBSD car doas lui-même fait partie d'OpenBSD. Cependant, même si vous n'apportez que la partie doas de la source OpenBSD, certaines choses sont insuffisantes en l'état, et la compilation sur un autre système d'exploitation ne sera pas fluide. Par conséquent, un package au niveau source est disponible sur Github afin qu'il puisse être compilé sur d'autres OS tels que Linux.
https://github.com/slicer69/doas/
Tout d'abord, extrayez cette source localement avec git clone.
$ git clone https://github.com/slicer69/doas.git
----- (Omission) -----
$ cd doas
$ ls -F
LICENSE README.md doas.1 doas.conf.5 env.c
Makefile compat/ doas.c doas.h parse.y
$
Comme vous pouvez le voir dans la liste des fichiers, doas est écrit en C.
Selon README.md, sous Linux, vous pouvez compiler avec make et installer avec make install, donc il ne semble y avoir rien de difficile. Alors compilons-le immédiatement. J'ai essayé ce qui suit sur Debian, mais j'ai confirmé qu'Ubuntu peut faire exactement la même chose.
Afin de compiler des programmes C avec Debian, vous avez besoin du paquet build-essential, qui est l'environnement de développement, alors installez d'abord build-essential.
$ sudo apt update
----- (Omission) -----
$ sudo apt -y install build-essential
----- (Omission) -----
$
Bien sûr, si vous avez déjà préparé l'environnement de développement, vous pouvez omettre ce travail.
Compilons-le réellement.
$ 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:Il n'y a pas de tel fichier ou répertoire
#include <security/pam_appl.h>
^
compilation terminated.
<Intégré>:cible'doas.o'Échec de la recette
make: *** [doas.o]Erreur 1
$
Si le fichier d'en-tête pam_appl.h n'est pas trouvé, une erreur se produit et la compilation s'arrête. Si vous le recherchez, pam_appl.h est ce dont vous avez besoin pour créer un programme qui utilise PAM. En fait, README.md a déclaré que libpam0g-dev est nécessaire (README.md doit être lu attentivement ^^;).
$ sudo apt -y install libpam0g-dev
Jetons un second regard et réessayons de compiler
$ 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:Commande non trouvée
Makefile:54:cible'y.tab.o'Échec de la recette
make: *** [y.tab.o]Erreur 127
$
Sans la commande yacc, j'ai eu une erreur et la compilation s'est terminée, et j'ai remarqué que build-essential n'incluait pas yacc (c'est vrai). Debian vous permet de choisir un paquet parmi plusieurs implémentations yacc, mais ici nous allons installer la version Berkeley de yacc byacc et la compiler à nouveau. Même si vous installez bison au lieu de byacc, vous pouvez toujours compiler dans Debian / Ubuntu.
$ sudo apt -y install byacc
----- (Omission) -----
$ 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
----- (Omission) -----
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
$
Maintenant que la compilation est terminée, il est temps d'installer.
$ 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/
$
Comme vous pouvez le voir à partir de la commande exécutée, les fichiers réellement installés par make install sont affichés dans le tableau suivant.
| Fichier | Contenu du fichier |
|---|---|
| /usr/local/bin/doas | corps de programme des doas |
| /usr/local/man/man1/doas.1 | commande doas elle-même fichier man |
| /usr/local/man/man5/doas.conf.5 | doas.fichier man conf |
Avec ce nombre de fichiers, il n'est pas difficile de gérer des programmes même non compressés. Si vous devez désinstaller doas à l'avenir, supprimez simplement ces trois fichiers et le fichier de configuration doas /usr/local/etc/doas.conf.
Après avoir installé doas, préparez doas.conf, mais ici j'ai préparé le même jeu dans FreeBSD dans / usr / local / etc.
Dans le cas de Debian, l'exécution de doas est enregistrée dans /var/log/auth.log comme dans FreeBSD, mais lorsque des options sont spécifiées pour la commande à exécuter, elle est explicitement séparée de la commande en raison de la bibliothèque d'analyse d'options. Il semble qu'il soit nécessaire de spécifier "-" indiquant.
$ doas id
uid=0(root) gid=0(root) groups=0(root)
$ doas tail -2 /var/log/auth.log
doas: invalid option -- '2'← «2» est traité comme une option de doas lui-même et une erreur se produit
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
J'ai également essayé de compiler et d'installer des doas sur CentOS.
Si vous ne préparez pas le fichier d'en-tête PAM et yacc, le même problème que Debian se produira, donc je l'ai installé avec gcc et je l'ai rendu nécessaire pour la compilation C. L'environnement de développement PAM utilise le package pam-devel et yacc utilise le package byacc.
$ sudo yum install gcc make pam-devel byacc
----- (Omission) -----
$ 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
----- (Omission) -----
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
----- (Omission) -----
$
Il n'y a aucune différence entre les fichiers installés et le cas de Debian.
Dans le cas de CentOS, si bison est déjà installé, il n'est pas nécessaire d'installer nouvellement byacc, et vous pouvez compiler en démarrant make avec make YACC = 'bison -y'.
Définissez doas.conf comme dans le système d'exploitation déjà introduit et vérifiez le fonctionnement de doas avec la commande id. Dans le cas de CentOS, l'enregistrement d'exécution de doas est / 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
Puisque la source de doas a été étendue localement, j'ai pensé à cette fois et j'ai simplement comparé l'échelle de la source avec sudo par le nombre de lignes.
sudo est compté avec le dernier sudo-1.8.28p1.tar.gz au moment de la rédaction de cet article.
$ 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*
$
Puisque sudo contient de nombreux fichiers de bibliothèque en plus du corps principal de sudo, j'ai compté les fichiers source C (* .c) et les fichiers d'en-tête (* .h) dans le répertoire src. [^ 3]
[^ 3]: Je n'ai pas confirmé si la source de la partie principale de sudo est en fait uniquement cette plage.
$ find src -type f -name '*.[ch]' | xargs wc -l
76 src/preload.c
735 src/exec_monitor.c
----- (Omission) -----
113 src/sudo_exec.h
197 src/get_pty.c
12612 total
$
Vous pouvez voir qu'il y a environ 12600 lignes. Au fait, quand j'ai compté tous les fichiers correspondant à *. [Ch] inclus dans le paquet source, il y avait plus de 100 000 lignes, et j'ai été honnêtement très surpris.
D'autre part, doas a environ 1200 lignes comme indiqué ci-dessous, ce qui est très petit par rapport à sudo.
$ 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
$
Les bibliothèques requises pour le portage vers un système d'exploitation non OpenBSD se trouvent dans le répertoire compat, mais même si toutes celles-ci sont comptées, le paquet source doas fait environ 3000 lignes.
Plus la source est petite, mieux c'est, mais plus la source est grande, plus le risque d'inclure des défauts est élevé.
Dans mon cas, sudo utilise souvent les options -u et -s, mais doas leur permet également d'utiliser la même fonctionnalité avec les mêmes spécifications d'options. En d'autres termes, sudo n'est pas nécessaire s'il y a des doas dans mon domaine d'utilisation, j'ai donc désinstallé sudo du système dans l'environnement FreeBSD.
Cependant, comme certains de mes propres scripts shell utilisent sudo, j'ai défini sudo comme lien symbolique vers doas, y compris le support immédiat jusqu'à ce qu'il soit réécrit.
$ 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 ← La substance de sudo d'ici est doas
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
$ sudo -V ← sudo est-Option pour afficher la version en V mais pas en doas
doas: illegal option -- V
usage: doas [-ns] [-a style] [-C config] [-u user] command [args]
$
Dans le cas de Linux, certaines distributions Linux peuvent construire le système en supposant qu'il existe sudo, donc si vous supprimez sudo du système, doas n'est pas exactement la même chose que sudo. Faisons-le après avoir compris qu'il n'y a pas de problème et jugé qu'il n'y a pas de problème. Il n'est pas nécessaire de forcer la suppression de sudo.
Même si une vulnérabilité est découverte dans sudo, il n'y a aucun risque d'être attaqué à distance du fait de la nature de la commande. Vous n'avez pas à vous précipiter pour prendre des mesures, surtout si le serveur n'est utilisé que par vous ou par une personne de confiance. En ce sens, il n'est peut-être pas nécessaire de passer aux doas sur un serveur privé, mais personnellement, si vous souhaitez utiliser la même fonction, vous devez en choisir une simple. Pour cette raison, je pense que c'était la bonne réponse d'introduire des doas cette fois.