[HS]/etc/sudoers

Le Mon, 5 Dec 2016 20:51:35 +0100,
Christophe Musseau <christo.2so@gmail.com> a écrit :

Bonsoir la liste.

Je souhaiterais empêcher les utilisateurs ayant accès à la commande
sudo d'éditer le fichier /etc/sudoers.
J'ai bien inséré la ligne dans mon fichier:
nom_Utilisateur ALL=(ALL:ALL) ALL,!/usr/sbin/visudo
J'ai ensuite lancé un:
#chown 700 /etc/sudoers
Mais l'utilisateur peut de son côté éditer le fichier et l e modifier
par: $sudo vim /etc/sudoers

Bref, peut-être que je me leurre. A partir du moment où je donne
accès à la commande sudo à des utilisateurs, je me tire un e balle
dans le pied pour ce qui est de la sécurité de ce fichier.

Merci pour vos éventuelles idées

Pour ma part, tout est interdit.
Je n'autorise que quelques commandes.

Exemple pour l'utilisateur toto
# /etc/sudoers.d/toto
#
# This file MUST be edited with the 'visudo -f ' command as root.
#
# See the man page for details on how to write a sudoers file.
#

# Host alias specification
# Address range from which command can be used
Host_Alias NOC = 192.168.1.0/255.255.255.0
Host_Alias LOC = machine.fqdn, machine,localhost

# User alias specification
User_Alias ADMIN_TEAM = root, toto

# Cmnd alias specification
# tail in /var/log directory only
Cmnd_Alias TAIL = /usr/bin/tail /var/log/*
# Debian tools for administration
Cmnd_Alias DEBIAN_TOOLS = /usr/bin/aptitude,
/usr/bin/apt-cache,
/usr/bin/apt-file,
/usr/bin/apt-get,
/usr/bin/synaptic,
/usr/bin/dpkg,
/usr/bin/dpkg-reconfigure
# stop running system
Cmnd_Alias START_STOP = /sbin/halt,
/sbin/reboot
# managing network interface
Cmnd_Alias NETWORK = /sbin/ifup,
/sbin/ifdown,
/etc/init.d/fwbuilder,
/usr/bin/wireshark,
/usr/bin/tshark,
/sbin/iwlist,
/sbin/iwconfig,
/usr/sbin/wifi-radar,
/usr/sbin/wpa_gui,
/opt/wicd/gui.py

# User privilege specification
root ALL=(ALL:ALL) ALL

ADMIN_TEAM NOC = NOPASSWD: DEBIAN_TOOLS, TAIL
toto LOC = NOPASSWD: DEBIAN_TOOLS, TAIL, START_STOP,NETWORK



--
Jack.R

--047d7b5d382a53ecf00542f693e8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bonjour

Ils sont dans le groupe sudo ou wheel ?

Cordialement.

Christophe Leloup

Le 5 décembre 2016 à 20:51, Christophe Musseau <christo.2so@gmail .com> a
écrit :

Bonsoir la liste.

Je souhaiterais empêcher les utilisateurs ayant accès à la commande sudo
d'éditer le fichier /etc/sudoers.
J'ai bien inséré la ligne dans mon fichier:
nom_Utilisateur ALL=(ALL:ALL) ALL,!/usr/sbin/visudo
J'ai ensuite lancé un:
#chown 700 /etc/sudoers
Mais l'utilisateur peut de son côté éditer le fichier et l e modifier par:
$sudo vim /etc/sudoers

Bref, peut-être que je me leurre. A partir du moment où je donn e accès à
la commande sudo à des utilisateurs, je me tire une balle dans le pi ed pour
ce qui est de la sécurité de ce fichier.

Merci pour vos éventuelles idées


--
Christophe MUSSEAU

(sous Debian GNU/Linux - https://www.debian.org)

--047d7b5d382a53ecf00542f693e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr">Bonjour<div><br></div><div>Ils sont dans le groupe sudo ou wheel ?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">   C ordialement.<br><br>Christophe Leloup</div></div>
<br><div class="gmail_quote">Le 5 décembre 2016 à 20:51, Christ ophe Musseau <span dir="ltr">&lt;<a href="mailto:christo.2so@gmail.com" target="_blank">christo.2so@gmail.com</a>&gt;</span> a écrit :<br>< blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><di v><div><div><div>Bonsoir la liste.<br><br></div>Je souhaiterais empêch er les utilisateurs ayant accès à la commande sudo d&#39;édi ter le fichier /etc/sudoers.<br></div>J&#39;ai bien inséré la lig ne dans mon fichier:<br></div>nom_Utilisateur ALL=(ALL:ALL) ALL,!/usr/sbi n/visudo<br></div>J&#39;ai ensuite lancé un:<br></div>#chown 700 /etc/ sudoers<br></div>Mais l&#39;utilisateur peut de son côté édi ter le fichier et le modifier par:<br></div>$sudo vim /etc/sudoers<br><br>< /div>Bref, peut-être que je me leurre. A partir du moment où je d onne accès à la commande sudo à des utilisateurs, je me tire une balle dans le pied pour ce qui est de la sécurité de ce fich ier.<br><br></div>Merci pour vos éventuelles idées<span class=" HOEnZb"><font color="#888888"><br><br clear="all"><div><div><div><div>< div><div><div><div><div><div><div><div><div><br>-- <br><div class="m_5599 261983488063523gmail_signature" data-smartmail="gmail_signature"><div dir ="ltr"><div><div dir="ltr">Christophe MUSSEAU</div><div dir="ltr">  </div><div>(sous Debian GNU/Linux - <a href="https://www.debian.org" t arget="_blank">https://www.debian.org</a>)<br><br></div></div></div></div >
</div></div></div></div></div></div></div></div></div></div></div></div></d iv></font></span></div>
</blockquote></div><br></div>

--047d7b5d382a53ecf00542f693e8--

Le Mon, Dec 05, 2016 at 10:31:51PM +0100, Jack.R a écrit :

Je n'autorise que quelques commandes.

...

# Debian tools for administration
Cmnd_Alias DEBIAN_TOOLS = /usr/bin/aptitude,
/usr/bin/apt-cache,
/usr/bin/apt-file,
/usr/bin/apt-get,
/usr/bin/synaptic,
/usr/bin/dpkg,

Un sudoeur un peu futé peut donc créer un paquet au format Debian qui va
modifier /etc/sudoers via ses « scripts du responsable » scripts de
pré/post (dés)-installation, ou lancer toute autre commande de son gré :)

Comme dit la page de manuel en anglais il est difficile d'empêcher un sudoeur
déterminé de lancer la commande qu'il veut en tant qu'administrateur (« There
is no easy way to prevent a user from gaining a root shell if that user is
allowed to run arbitrary commands via sudo »).

Amicalement,

--
Charles, depuis l'aéroport de Naha, Okinawa, Japon :)

--=-=- Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

❦ 5 décembre 2016 22:31 +0100, "Jack.R" <jack.r@free.fr>  :

Cmnd_Alias NETWORK = /sbin/ifup,
/sbin/ifdown,

Ces deux commandes permettent de fournir un fichier de configuration
séparé.

/usr/bin/wireshark,
/usr/bin/tshark,

Préférable de les lancer en non root et de configurer dumpcap pou r être
exécuté par l'utilisateur (dpkg-reconfigure wireshark-common).
--
Choose a data representation that makes the program simple.
- The Elements of Programming Style (Kernighan & Plauger)

--=-=- Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAlhHxGgACgkQlaQv6DU1
Jfm3pA//UWNzt9Eo8KShURmAZ1xm7oTuoMYt4CKp8NSTLubl4X/UPBX+k9Cr+Cnd
3pZD2xqH2CcocR5SRey4/0Pv92EFvYB/KyBNQSXIANdaYMI2JbX1vQMtteeM6E5s
TeFxaPW97q/s2M22Zn4xyo9jBkXRzBbUVBaTvjGNCP97DZbPCgYsJPsdMG+wHBJc
M6QnE7Is9WE7atzFd/cwAXGkIfUtipPz36m9r/ctJWccRT2DnpBEkBZJWkwENkmD
Ug7f5t4mouKW7C5q1bsEtRTdsEMYG+0uQFF4aESvO0E2iPw4OIKfXw2q+Pf0dJuC
WpTIkfHB8+ncmtceCSrz6550oFOSqF6JJ2l5e/BQRLUUB7FPaEsLY8GCxCRQkVVi
DX29NKJlQGJNjV/HB3rwojMWRzeyb+KFQOxruRC/hRDik2GpoMbB6ddDXC4i5xXz
nBXi7w6a6AwHKCH8pxy3zAYazkmhar1gemrcLJ8NGD6k5QwEtAg7RN7Q+EbWYuB7
FVcePzzggTTMp5pK0I/sczLuJqRY/05j3BGfkIfiyQHDg2XWSXJ4nF2/agebQ+4Z
2X1fVHcCBkqHgEWOjqp1uC/ktH1qsLsz94UGDDvY7t81c2YDsBBzpfkaBeeM9pQ2
wade08QYk0n+wPglvGeTiz40FO6c+IFdd7gJjf7tQn92GTl+ORk =KR4p
-----END PGP SIGNATURE-----
--=-=-=--

Charles Plessy a écrit :

Le Mon, Dec 05, 2016 at 10:31:51PM +0100, Jack.R a écrit :

Je n'autorise que quelques commandes.

...

# Debian tools for administration
Cmnd_Alias DEBIAN_TOOLS = /usr/bin/aptitude,
/usr/bin/apt-cache,
/usr/bin/apt-file,
/usr/bin/apt-get,
/usr/bin/synaptic,
/usr/bin/dpkg,

Un sudoeur un peu futé peut donc créer un paquet au format Debian qui va
modifier /etc/sudoers via ses « scripts du responsable » scripts de
pré/post (dés)-installation, ou lancer toute autre commande de son gré :)

Comme dit la page de manuel en anglais il est difficile d'empêcher un sudoeur
déterminé de lancer la commande qu'il veut en tant qu'administrateur (« There
is no easy way to prevent a user from gaining a root shell if that user is
allowed to run arbitrary commands via sudo »).

Eh oui. C'est bien pour cela que je ne configure jamais ce truc. C'est
une fausse bonne idée puisque sudo permet l'exploitation d'une
foultitude de failles qu'il a lui même ouvert. Il y a effectivement la
faille apt/dpkg, mais il y a tout un tas de trucs bien plus sournois et
difficilement prévisibles.

Cordialement,

JKB

--001a1143df26f750ff054311f698
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Un sudoeur un peu futé peut donc créer un paquet au format Debi an qui va
modifier /etc/sudoers via ses « scripts du responsable » script s de
pré/post (dés)-installation, ou lancer toute autre commande de son gré :)

Comme dit la page de manuel en anglais il est difficile d'empêcher u n
sudoeur
déterminé de lancer la commande qu'il veut en tant qu'administr ateur («
There
is no easy way to prevent a user from gaining a root shell if that user i s
allowed to run arbitrary commands via sudo »).

Eh oui. C'est bien pour cela que je ne configure jamais ce truc.
C'est une fausse bonne idée puisque sudo permet l'exploitation d'une
foultitude de failles qu'il a lui même ouvert. Il y a effectivement la
faille apt/dpkg, mais il y a tout un tas de trucs bien plus sournois et
difficilement prévisibles.


Sans avoir la maitrise de toutes les possibilités de configuration, je
note, à vous lire les uns et les autres, que sudo est une véritab le boîte
de Pandore.
En tout cas j'en ai appris un peu plus et vais consommer sudo avec
modération.
Merci pour vos contributions

--001a1143df26f750ff054311f698
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="auto"><div class="gmail_extra" dir="auto"><div class="gma il_quote"><br><blockquote class="m_3649438659820006313quote" style="mar gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m _3649438659820006313elided-text"><blockquote class="gmail_quote" style= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Un sudoeur un peu futé peut donc créer un paquet au format Debian qui va<br>
modifier /etc/sudoers via ses « scripts du responsable » scripts de<br>
pré/post (dés)-installation, ou lancer toute autre commande de so n gré :)<br>
<br>
Comme dit la page de manuel en anglais il est difficile d&#39;empêcher un sudoeur<br>
déterminé de lancer la commande qu&#39;il veut en tant qu&#39;adm inistrateur (« There<br>
is no easy way to prevent a user from gaining a root shell if that user is< br>
allowed to run arbitrary commands via sudo »).<br>
</blockquote>
<br></div>
        Eh oui. C&#39;est bien pour cela que je ne conf igure jamais ce truc. C&#39;est une fausse bonne idée puisque sudo per met l&#39;exploitation d&#39;une foultitude de failles qu&#39;il a lui mà ªme ouvert. Il y a effectivement la faille apt/dpkg, mais il y a tout un tas de trucs bien plus sournois et difficilement prévisibles.<br></blo ckquote></div></div><div dir="auto"><br></div><div dir="auto">Sans avoi r la maitrise de toutes les possibilités de configuration, je note, à vous lire les uns et les autres, que sudo est une véritable bo îte de Pandore. </div><div dir="auto">En tout cas j&#39;en ai a ppris un peu plus et vais consommer sudo avec modération.</div><div di r="auto">Merci pour vos contributions</div><div class="gmail_extra" dir ="auto"><div class="gmail_quote"><blockquote class="m_364943865982000 6313quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le ft:1ex"></blockquote></div></div></div>

--001a1143df26f750ff054311f698--

Le Wed, 07 Dec 2016 09:12:24 +0100,
Vincent Bernat <bernat@debian.org> a écrit :

❦ 5 décembre 2016 22:31 +0100, "Jack.R" <jack.r@free.fr>  :


> /usr/bin/wireshark,
> /usr/bin/tshark,

Préférable de les lancer en non root et de configurer dumpcap p our
être exécuté par l'utilisateur (dpkg-reconfigure wireshark -common).

Merci pour la remarque, cela m'a permis de me rendre compte qu'il
fallait que je fasse un peu de ménage sur des choses devenues obsolà ¨tes
avec le temps.

--
Jack.R

Le Tue, 6 Dec 2016 16:38:29 +0900,
Charles Plessy <plessy@debian.org> a écrit :

Le Mon, Dec 05, 2016 at 10:31:51PM +0100, Jack.R a écrit :
>
> Je n'autorise que quelques commandes.
...
> # Debian tools for administration
> Cmnd_Alias DEBIAN_TOOLS = /usr/bin/aptitude,
> /usr/bin/apt-cache,
> /usr/bin/apt-file,
> /usr/bin/apt-get,
> /usr/bin/synaptic,
> /usr/bin/dpkg,

Un sudoeur un peu futé peut donc créer un paquet au format Debi an qui
va modifier /etc/sudoers via ses « scripts du responsable  » scripts de
pré/post (dés)-installation, ou lancer toute autre commande de son
gré :)

Comme dit la page de manuel en anglais il est difficile d'empêcher un
sudoeur déterminé de lancer la commande qu'il veut en tant
qu'administrateur (« There is no easy way to prevent a user from
gaining a root shell if that user is allowed to run arbitrary
commands via sudo »).

Amicalement,

Le sudoeur en question doit faire partie du groupe ADMIN_TEAM
(administration distante) ou être loggé en tant que toto
(administration locale).
Il s'agit donc de personnes dites de confiance dans la mesure où on
leur a délégué une part d'administration de la machine.
Si elles ne sont pas de confiance, il n'y a aucune raison de donner des
droits sudo.

--
Jack.R

Le 17142ième jour après Epoch,
Jack R. écrivait:

Le sudoeur en question doit faire partie du groupe ADMIN_TEAM
(administration distante) ou être loggé en tant que toto
(administration locale).
Il s'agit donc de personnes dites de confiance dans la mesure où on
leur a délégué une part d'administration de la machine.
Si elles ne sont pas de confiance, il n'y a aucune raison de donner des
droits sudo.

Du coup, si ce sont des personnes de confiance, autant leur donner
l'ensemble des droits, plutôt que de passer par sudoers ;)

Le seul usage de sudoers que je fais, pour ma part, c'est la possibilità ©
de passer en root depuis mon user normal sans être obligé de rent rer le
mot de passe. Et ce, uniquement sur mon poste de travail.

On Wed, Dec 07, 2016 at 08:27:08PM +0100, François TOURDE wrote:

Le seul usage de sudoers que je fais, pour ma part, c'est la possibilité
de passer en root depuis mon user normal sans être obligé de rentrer le
mot de passe. Et ce, uniquement sur mon poste de travail.

C'est pas tout à fait pareil: un avantage de sudoers, c'est
d'attribuer des droits qu'on peut révoquer par utilisateurs,
alors que si tu donnes le mot de passe root, il faut changer
le mot de passe et le redistribuer si tu veux retirer les
droits à un utilisateur.

Perso, c'est plutôt le contraire: je ne conçois pas un
serveur partagé où on s'amuse à distribuer le mot de passe
root.

Y.