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
j’adore ta tirade
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.
“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).
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.
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