Vous n'êtes pas identifié(e).
Pages : 1
Et très logiquement, j'ai maintenant accès à ces commandes sans avoir besoin de sudo.
Si je trouve cela très pratique, je trouve cela limite en terme de sécurité.
Est-ce à dire qu'il suffit à un utilisateur de modifier son .bashrc pour avoir accès à des commandes qui lui sont interdites par l'admin ou par défaut par le système?
J'ai fait quelques recherches sur le net sans pour autant trouver une explication intelligible, notamment en ce qui concerne la relation entre le $PATH et les autorisations définies dans /etc/sudoers.
Si une âme charitable voulait bien éclairer un peu ma lanterne d'apprenti fouilleur d'entrailles linuxo-debianesques, ce serait super!
Dernière modification par sogal (28-08-2013 12:54:52)
Hors ligne
Dernière modification par MicP (28-08-2013 01:26:43)
Si je trouve cela très pratique, je trouve cela limite en terme de sécurité.
Ça ne change pas grand-chose : tu peux très bien lancer une commande par son chemin absolu.
La sécurité réside plus dans le fait d'être autorisé ou non à lancer cette commande, que tu aies sbin dans ton path ou que tu tapes /sbin/lacommande.
Donc, je penche plutôt vers /etc/sudoers.
Hors ligne
Je peux donc appeler blkid, ifconfig, etc. en utilisateur simple.
Lorsque je veux utiliser ces commandes pour modifier la configuration du système, je ne peux pas :
Des droits plus importants étant nécessaires. Je passe alors root pour lancer ces commandes.
Interdire l'exécution de ces commandes est inutile, puisqu'il suffit à l'utilisateur de les compiler lui-même pour y avoir accès.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
“ La première loi du libre et de tout hacker, au sens noble, le partage de la connaissance ”
.
Aptosid-Kde-Full (4.3.0-0.slh.2-aptosid-amd64/ aptosid 4.3-2 (2015-11-18))
Hors ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
donc en gros le changement de $PATH n'est qu'une forme de "raccourci" et n'a aucun rapport avec la sécurisation du système.
Exactement
PAM, il me semblait que c'était plus pour les méthodes d'authentification (genre login par clé usb, empreinte digitale, authentification par ldap, etc.) que pour affecter des droits aux gens.
Pour ça, il y a les groupes.
Par exemple, si vous regardez l'application « pmount » elle a besoin de droit root, donc elle appartient à root et est setuid. Seulement, pour que seuls les membres d'un groupe particulier puisse s'en servir, l'application appartient au groupe plugdev et n'est pas exécutable par les autres ! (permissions 754)
Si un autre utilisateur compile pmount, il pourra mettre l'appli setuid, mais ne pourra pas définir root comme propriétaire
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Hors ligne
PAM, il me semblait que ...
Bien plus que cela, en grattant un peu ... la pause café, la vaisselle, les poussières, le vide grenier, barrage, respect, interdit, dégaine ... ^¿~
PAM, entre autres !
“ La première loi du libre et de tout hacker, au sens noble, le partage de la connaissance ”
.
Aptosid-Kde-Full (4.3.0-0.slh.2-aptosid-amd64/ aptosid 4.3-2 (2015-11-18))
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
“ La première loi du libre et de tout hacker, au sens noble, le partage de la connaissance ”
.
Aptosid-Kde-Full (4.3.0-0.slh.2-aptosid-amd64/ aptosid 4.3-2 (2015-11-18))
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Pages : 1