5 nouvelles fonctionnalités sudo que les administrateurs système doivent connaître en 2022

Les versions récentes de Sudo ont ajouté de nouvelles fonctionnalités qui vous permettent de surveiller et de contrôler les zones à problèmes auparavant cachées.

Lorsque vous souhaitez accorder un accès administratif à certains de vos utilisateurs tout en contrôlant et vérifiant ce qu'ils font sur vos systèmes, vous utilisez sudo. Cependant, même avec sudo, il existe de nombreux problèmes invisibles : pensez simplement à accorder un accès au shell. Les versions récentes de sudo ont ajouté des fonctionnalités qui vous permettent de voir ces problèmes et même de les contrôler. Par exemple, vous pouvez activer des messages de journal plus détaillés et plus faciles à traiter et enregistrer chaque commande exécutée dans une session shell.

Certaines de ces fonctionnalités sont toutes nouvelles. Certains d'entre eux s'appuient sur des fonctionnalités introduites dans la version 1.9.0 ou même antérieure. Par exemple, sudo pouvait enregistrer tout ce qui se passait sur un terminal, même en version 1.8. Cependant, le système stockait ces enregistrements localement, et ils étaient faciles à supprimer, notamment ceux où les enregistrements étaient les plus utiles : les sessions Shell. La version 1.9.0 a ajouté une collection centrale d'enregistrements de session, de sorte que les enregistrements ne peuvent pas être supprimés par l'utilisateur local, et les versions récentes ont ajouté des relais, rendant la collection encore plus robuste.

Si vous ne connaissez que les bases de sudo ou si vous n'avez utilisé que la version 1.8 auparavant, je vous recommande de lire mon article précédent.

1. Journalisation au format JSON

La première nouvelle fonctionnalité que je souhaite introduire est la journalisation au format JSON. Je suis un fanatique de la journalisation (j'ai commencé à travailler sur le projet syslog-ng il y a douze ans), et cette fonctionnalité est la première introduite depuis mon article sur Opensource.com. Lorsqu'il est activé, sudo enregistre beaucoup plus d'informations et le fait de manière plus simple à analyser.

Les messages syslog traditionnels de sudo sont courts et ne contiennent que le minimum d'informations nécessaires. Cela est dû aux contraintes des anciennes implémentations de syslog : les messages de plus de 1 Ko étaient ignorés ou tronqués :

Jan 28 13:56:27 localhost.localdomain sudo[10419]: czanik : TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash

Les implémentations plus récentes de syslog peuvent gérer des tailles de messages beaucoup plus grandes. syslog-ng accepte par défaut les messages de journal d'une taille allant jusqu'à 64 Ko (mais bien sûr, ils peuvent être plus petits ou plus grands, selon la configuration réelle).

Le même événement contient beaucoup plus d'informations s'il est connecté au format JSON. Plus ne signifie pas plus difficile à gérer : les messages au format JSON sont plus faciles à analyser par de nombreux logiciels de gestion de journaux. Voici un exemple:

Jan 28 13:58:20 localhost.localdomain sudo[10518]: @cee:{"sudo":{"accept":{"uuid":"616bc9efcf-b239-469d-60ee-deb5af8ce6","server_time":{"seconds":1643374700,"nanoseconds":222446715,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submit_time":{"seconds":1643374700,"nanoseconds":209935349,"iso8601":"20220128125820Z","localtime":"Jan 28 13:58:20"},"submituser":"czanik","command":"/bin/bash","runuser":"root","runcwd":"/home/czanik","ttyname":"/dev/pts/0","submithost":"localhost.localdomain","submitcwd":"/home/czanik","runuid":0,"columns":118,"lines":60,"runargv":["/bin/bash"],"runenv":["LANG=en_US.UTF-8","HOSTNAME=localhost.localdomain","SHELL=/bin/bash","TERM=xterm-256color","PATH=/home/czanik/.local/bin:/home/czanik/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin","MAIL=/var/mail/root","LOGNAME=root","USER=root","HOME=/root","SUDO_COMMAND=/bin/bash","SUDO_USER=czanik","SUDO_UID=1000","SUDO_GID=1000"]}}}

Vous pouvez activer les messages de journal au format JSON dans le fichier sudoers :

Defaults log_format=json

Vous pouvez en savoir plus sur l'utilisation des messages de journal au format JSON à partir de sudo sur mon blog syslog-ng.

2. Collecte centralisée des journaux à l'aide de sudo_logsrvd

Une autre fonctionnalité liée à la journalisation dans la version 1.9.4 consiste à collecter tous les messages de journal sudo (y compris les échecs) à l'aide de sudo_logsrvd. Auparavant, le système enregistrait les sessions réussies uniquement lorsque sudo_logsrvd effectuait réellement un enregistrement. La journalisation se fait toujours via syslog par défaut en fin de compte.

Pourquoi est-ce important? Tout d'abord, vous pouvez collecter tout ce qui concerne sudo en un seul endroit : à la fois les enregistrements de session et tous les messages de journal correspondants. Deuxièmement, il peut également garantir une journalisation appropriée de tous les événements liés à sudo, car sudo peut refuser d'exécuter des commandes si sudo_logsrvd est inaccessible.

Vous pouvez activer la journalisation sur sudo_logsrvd avec le paramètre suivant dans le fichier sudoers (bien sûr, remplacez l'adresse IP) :

Defaults log_servers=172.16.167.150

Si vous souhaitez des messages de journal au format JSON, vous avez besoin du paramètre suivant dans la section [eventlog] de la configuration sudo_logsrvd :

log_format = json

Sinon, sudo_logsrvd utilise le format de journal sudo traditionnel avec une simple modification : il inclut également des informations sur l'hôte d'où provient le journal :

Nov 18 12:40:16 centos8splunk.localdomain sudo[21028]:   czanik : 3 incorrect password attempts ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Nov 18 12:40:23 centos8splunk.localdomain sudo[21028]:   czanik : HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; TSID=00000A ; COMMAND=/bin/bash
Nov 18 12:40:30 centos8splunk.localdomain sudo[21028]:   czanik : command rejected by I/O plugin ; HOST=centos7sudo.localdomain ; TTY=pts/0 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash

3. Relais

Lorsqu'ils ont initialement introduit sudo_logsrvd (version 1.9.0) pour la collecte centrale des enregistrements de session, les clients ne pouvaient envoyer que des enregistrements directement. La version 1.9.7 a introduit le concept de relais. Avec les relais, au lieu d'envoyer directement des enregistrements, vous pouvez envoyer des enregistrements à plusieurs niveaux d'hôtes intermédiaires, qui structurent votre réseau.

Pourquoi est-ce important? Tout d'abord, les relais permettent de collecter des enregistrements de sessions même si l'hôte central est indisponible en raison de problèmes de réseau ou de maintenance. Par défaut, sudo refuse de s'exécuter lorsqu'il ne peut pas envoyer d'enregistrements, afin que les relais puissent garantir que vous pouvez utiliser sudo 24 heures sur 24.

Deuxièmement, cela vous permet également d'avoir des contrôles plus stricts sur votre réseau : au lieu d'ouvrir le pare-feu pour tous les hôtes vers le sudo_logsrvd central, il vous suffit d'autoriser le passage de votre relais.

Enfin, il permet de collecter des enregistrements de sessions depuis des réseaux sans accès direct à Internet, comme les réseaux privés AWS, sur lesquels vous pouvez installer sudo_logsrvd en mode relais sur l'hôte passerelle.

Lorsque vous utilisez des relais, la configuration des clients sudo et du sudo_logsrvd central reste la même. Sur l'hôte relais, ajoutez la ligne suivante à la section [relay] de sudo_logsrvd.conf :

relay_host = 172.16.167.161

Si la connexion réseau vers le serveur central est problématique, vous pouvez configurer le relais pour stocker les enregistrements avant de les transférer :

store_first = true

4. Sous-commandes de journalisation

Avez-vous déjà voulu savoir ce qui se passe lors d'une session shell démarrée via sudo ? Oui, les enregistrements de session sont là, mais regarder des heures d'enregistrement juste pour voir quelques commandes exécutées est ennuyeux et une énorme perte de temps. Heureusement, la version 1.9.8 a introduit les sous-commandes de journalisation. Il suffit désormais de vérifier régulièrement vos messages de journal et de regarder les enregistrements uniquement lorsque quelque chose de suspect se produit.

Vous n'avez même pas besoin d'une règle pour autoriser l'accès au shell, il suffit d'accéder à un éditeur. La plupart des éditeurs peuvent exécuter des commandes externes. Mon éditeur préféré est JOE, et voici ce que vous pouvez voir lorsque je le démarre via sudo :

Aug 30 13:03:00 czplaptop sudo[10150]:   czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe

Rien d'intéressant, juste un éditeur, même si je génère un shell et supprime quelques fichiers et partitions de ce shell. Voyons maintenant ce qui se passe lorsque vous activez les sous-commandes de journalisation :

Aug 30 13:13:14 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/joe
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/sh -c /bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/bin/bash
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/readlink /proc/10889/exe
[...]
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/sed -r s@/*:|([^\\]):@\1\n@g;H;x;s@/\n@\n@
Aug 30 13:13:37 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/tty
Aug 30 13:13:42 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/id
Aug 30 13:13:56 czanik : TTY=pts/1 ; PWD=/home/czanik ; USER=root ; COMMAND=/usr/bin/ls -A -N --color=none -T 0 /usr/share/syslog-ng/include/scl/

J'ai omis des dizaines de lignes pour gagner de la place, mais vous pouvez toujours voir que j'ai démarré un shell, et les commandes exécutées par bash_profile sont également disponibles dans les logs.

Vous pouvez activer les sous-commandes de journalisation dans le fichier sudoers en utilisant le paramètre suivant :

Defaults log_subcmds

Dans les journaux sudo traditionnels, vous pouvez voir à partir de l'identifiant du processus sudo que ces journaux proviennent de la même session sudo. Si vous activez la journalisation au format JSON, comme indiqué précédemment, sudo enregistre beaucoup plus d'informations dans les journaux, ce qui facilite leur analyse.

5. Interception des sous-commandes

Les sous-commandes de journalisation suppriment la plupart des problèmes cachés de sudo, mais il existe des situations dans lesquelles vous ne souhaitez pas simplement regarder ce qui se passe, mais également contrôler le flux des événements. Par exemple, vous devez accorder l'accès au shell à un utilisateur tout en souhaitant l'empêcher d'exécuter une commande spécifique. L'interception est idéale dans de tels cas. Il existe bien sûr certaines limitations, comme par exemple que vous ne pouvez pas limiter les commandes intégrées des shells.

Disons que la commande who est dangereuse. Vous pouvez activer l'interception en deux étapes : la première l'active, la seconde la configure. Dans ce cas, mon utilisateur n'est pas autorisé à exécuter who :

Defaults intercept
czanik ALL = (ALL) ALL, !/usr/bin/who

Voici ce qui se passe lorsque je démarre une session root shell via sudo et que j'essaie d'exécuter who :

$ sudo -s
# who
Sorry, user czanik is not allowed to execute '/usr/bin/who' as root on czplaptop.
bash: /usr/bin/who: Permission denied

Vous pouvez facilement désactiver complètement les shells en cours d’exécution :

Defaults intercept
Cmnd_Alias SHELLS=/usr/bin/bash, /usr/bin/sh, /usr/bin/csh
czanik ALL = (ALL) ALL, !SHELLS

Cependant, cela signifie également que vous ne pouvez pas démarrer de sessions shell via sudo. Non seulement cela, mais vous ne pouvez pas non plus exécuter de commandes externes à partir d’éditeurs. Voici ce qui se passe lorsque j'essaie de démarrer la commande ls depuis vi :

$ sudo vi /etc/issue
Sorry, user czanik is not allowed to execute '/bin/bash -c /bin/ls' as root on czplaptop.
Cannot execute shell /bin/bash
Press ENTER or type command to continue

Quelle est la prochaine?

J'espère que la lecture de mon article vous donnera envie d'essayer vous-même ces nouvelles fonctionnalités. Vous pouvez installer la dernière version de sudo sur de nombreuses distributions Linux et variantes UNIX à partir de votre gestionnaire de packages, ou utiliser un programme d'installation binaire disponible sur le site Web Sudo.

Cet article ne vous donne qu’un aperçu des nouvelles possibilités. Si vous souhaitez en savoir plus sur ces fonctionnalités, visitez le site Web, qui héberge des pages de manuel, ainsi que le blog Sudo.