doas VS sudo

Bonjour,

sudo posant parfois de sérieux problèmes de sécurité, une alternative est proposée : doas, l’équivalent en provenance du monde OpenBSD.

Qu’en pensent les Sysops ?

Bug#981176: RFP: doas – minimal replacement for sudo

Le dernier souci sudo en date (CVE-2021-3156) :

[SECURITY] [DSA 4839-1] sudo security update
[SECURITY] [DLA 2534-1] sudo security update
ELA-351-1 sudo security update

Bonjour

Que même avec doas, si tu configures mal, tu peux te faire avoir, avec élévation de privilèges…
Il y a clairement des configurations à ne pas écrire.

1 J'aime

Ce qui compte c’est que les corrections arrivent

apt changelog sudo
Réception de :1 store: sudo 1.9.5p1-1.1 Changelog

sudo (1.9.5p1-1.1) unstable; urgency=high

  * Non-maintainer upload.
  * Heap-based buffer overflow (CVE-2021-3156)
    - Reset valid_flags to MODE_NONINTERACTIVE for sudoedit
    - Add sudoedit flag checks in plugin that are consistent with front-end
    - Fix potential buffer overflow when unescaping backslashes in user_args
    - Fix the memset offset when converting a v1 timestamp to TS_LOCKEXCL
    - Don't assume that argv is allocated as a single flat buffer

 -- Salvatore Bonaccorso <carnil@debian.org>  Wed, 20 Jan 2021 10:11:47 +0100

Sudo ne doit jamais etre utilisée: ce truc est une hérésie

Je précise que même si je suis sous ubuntu j’ai debianisé ma distro et désactivé sudo

ps: j’avais installé ubuntu car je n’avais pas de cable ethernet à un moment et qu’ubuntu reconnaissait ma carte wifi out-of-the-box donc je suis sous ubuntu par defaut

Mais bien sûr :speak_no_evil: :hear_no_evil: :see_no_evil:

1 J'aime

Sudo est comme si un coureur cycliste utilisait un velo à roulettes

“Unix never says please.”
– Rob Pike

J’avoue que perso je préfère comprendre comment gérer les permissions

En plus tu peux facilement hacker le compte root à partir de sudo

Capture d’écran du 2021-02-04 04-27-21

Sans compter le fait que sudo a très souvent d’énormes failles de sécurité

ps: enfin me semble t’il…c’est mon point de vue…et je m’en excuse

Bonjour

Plutôt que d’utiliser

sudo su -

il vaut mieux utiliser l’option i de la commande sudo

sudo -i

voir la page man de la commande sudo

man sudo
2 J'aime

Le vocabulaire utilisé montre bien que l’on est dans le domaine de la croyance et non de la raison. :wink:

Oh mon dieu la commande sudo permet à un utilisateur autorisé par sudoers de se substituer à root !

et @MicP +1000 (sudo su est une hérésie ânerie)

j’adore ta tirade :slight_smile:
Seulement tu omets un facteur important, multiplier les acteurs sur root est comme donner les codes nucléaires à plusieurs personnes.
Pas pour rien qu’il est déconseillé en tant que sysadmin d’utiliser sudo et plutot avoir une gestion pointue des permissions.

Rien ne t’empêche d’avoir un seul et unique utilisateur autorisé à se substituer à root.
Dans la pratique il est courant de donner un accès root a plusieurs personnes, notamment sur des serveurs qui ont besoin de maintenance 24/7. Et dans ce cas le faire via sudo permet dans une certaine mesure de savoir qui a fait quoi et à quel moment (via les logs).
Et sudoers permet de déléguer de manière extrêmement fine certains droits à certains utilisateurs.

Je n’ai jamais entendu personne déconseiller l’usage de sudo/sudoers par rapport à su et un compte root actif. Les deux systèmes ont leurs avantages, leurs et inconvénients et leurs cas d’usage mais il n’y en a pas un plus sécurisé que l’autre.

Tu fais ce que tu veux je dis juste que ds la pratique il est fortement deconseillé d’utiliser sudo

En plus sur des systemes dont le compte root est verrouillé comme le montre l’extrait de shadow plus haut

Déconseillé par qui ?


Quelques règles pour durcir sudo
Capture d’écran de 2021-02-04 14-39-49

C’est bien indiqué pendant l’installation que c’est mieux de ne pas créer de mot-de-passe root et d’utiliser sudo avec un user lambda

6.3.2. Création des utilisateurs et des mots de passe

2 J'aime

“There are less eyes on random doas ports, just because sudo had a vulnerability does not mean random doas ports are more secure if they are not reviewed or pam is configured incorrectly.”

La manière « recommandée », du côté d’OpenWRT par exemple, d’utiliser sudo que je connaisse est de l’utiliser ainsi, en décommentant ces deux lignes, ou en les écrivant :

# Defaults targetpw # Ask for the password of the target user
# ALL ALL=(ALL) ALL # WARNING: only use this together with 'Defaults targetpw'

Si le compte est unique, utilisé par plusieurs personnes, par définitoin, tu n’a pas moyen de savoir qui à fait quoi. Tu sais éventuellement le quoi, en fonction du paramétrage de sudo, mais tu ne sais pas qui, mais un groupe de qui, c’est à dire personne réellement identifiable.

En 2002/2003, Bouygues Telecom hebergeur dispose d’environs 2000 à 2500 serveurs unix (6 unix différents). Ces serveurs sont administrés par près de 450 à 500 personnes différentes.
La gestion originelle passait par des compte unique utilisés par plusieurs personnes; en aussi peu de temps que pour le dire, non seulement le compte unique avait débordé du groupe défini au départ mais au final, devant la complexité de la gestion des permission (comme le dit loic), la cellule sécurité avait défini que le niveau de sécurité était quasi nul: aussi bien par l’accès proprement, que les analyses à posteriori de leurs utilisations.

A l’époque, il a alors été décidé de changer la méthode. celel qui a été finalement décidée a été de continuer d’utiliser sudo mais avec une configuration dynamique: sudo + ldap en l’occurence.
la définition de groupe LDAP et l’inclusion dans ces groupes des utilisateurs permettait de remplir les condition d’identité des utilisateurs, de l’application dynamique des modifications de configurations, l’absolue ignorance du mot de passe root autrement que par un groupe de personne limité, qui pour pouvoir passer en root, nécessitait de passer par sudo, identifiant de fait la personne qui utilisait le compte. la centralisation des logs permettait dans le même temps de s’assurer de la pertinence de la traçabilité.

Sauf que ce n’est pas recommandé de laisser le compte root sans mot de passe. Ceci dit, ls discussions sur le sujet sont toujours ouverte, mais des failles utilisent notamment le fait que le compte root n’a pas de mot de passe. C’est même fortement déconseillé en terme de sécurité. Mettre un mot de passe root à l’installation n’empêche absolument pas le fait d’utiliser et d’imposer sudo.

cependant, certaines commandes sous sudo permettent d’échapper une session sous root (vi/vim par exemple).

Bonjour PengouinPdt

Un extrait de la page man de la commande sudo (de debian et ubuntu)
retourné par la ligne de commande suivante :

man --pager='less -p-i,' sudo

L’extrait retourné :

 -i, --login
             Run the shell specified by the target user's password data‐
             base entry as a login shell.  This means that login-spe‐
             cific resource files such as .profile, .bash_profile or
             .login will be read by the shell.  If a command is speci‐
             fied, it is passed to the shell for execution via the
             shell's -c option.  If no command is specified, an interac‐
             tive shell is executed.  sudo attempts to change to that
             user's home directory before running the shell.  The com‐
             mand is run with an environment similar to the one a user
             would receive at log in.  Note that most shells behave dif‐
             ferently when a command is specified as compared to an in‐
             teractive session; consult the shell's manual for details.
             The Command environment section in the sudoers(5) manual
             documents how the -i option affects the environment in
             which a command is run when the sudoers policy is in use.


1 J'aime

Je confonds avec su, dsl :wink:

Ah oui !
D’autant que le nom (login) de l’option sous sa forme longue
est le même et a les mêmes fonctionnalités pour su que pour sudo
quand c’est pour accéder aux privilèges du compte root

man --pager='less -p-,' su

extrait retourné :

-, -l, --login
       Start the shell as a login shell with an environment similar to a real login:
          o      clears all the environment  variables  except  TERM  and  variables
                 specified by --whitelist-environment
          o      initializes  the  environment variables HOME, SHELL, USER, LOGNAME,
                 and PATH
          o      changes to the target user's home directory
          o      sets argv[0] of the shell to '-' in order to make the shell a login
                 shell
1 J'aime