Lien The etymology of command line tools

À l'installation de la Fedora que j'utilise actuellement j'ai choisi de désactiver le compte root, et je peux exécuter les commandes nécessitant des privilèges élevés avec sudo. Mais étrangement mon user ne figure pas dans le fichier /etc/sudoers.
D'habitude (peut-être mauvaise) quand j'installe sudo sur une distro (même sur FreeBSD) j'ajoute la ligne :
user_name ALL=(ALL) ALL
à ce fichier.
1/ comment se fait-il que j'ai les droits root en utilisant sudo ?
2/ quand j'ajoute cette fameuse (…)
Je me pose cette question : sur un poste personnel, derrière une box quelconque, les utilisateurs doivent-ils avoir des mots de passe forts, et donc difficiles à retenir/frapper ? Pareil pour root, qui d'ailleurs peut être désactivé (le mdp pas le compte) sur certaines distros (ici Fedora) en choisissant un utilisateur qui aura les droits sudo ALL ALL (mal formulé mais vous comprendrez).
Question subsidiaire : y-a-t il moyen de voir quelle sont les attaques sur ces comptes ?
Une nouvelle version de sudo est sortie. Elle corrige une faille assez sévère.
L'option pwfeedback
est une option qui offre un retour visuel lors de la saisie du mot de passe, en affichant des étoiles. Le bogue entraîne un dépassement de tampon, notamment lorsqu’un utilisateur, même non enregistré, tape ^U
(effacer la ligne) sur un longue chaîne.
Cette option est désormais ignorée dans un environnement hors TTY, propice à ce comportement. Elle est toutefois rarement activée par défaut.
Cette (…)
Le module RAR (Root As Role) implémente une approche basée sur les rôles pour distribuer les privilèges aux utilisateurs. Il fournit une solution qui permet aux utilisateurs de contrôler la liste des privilèges qu’ils accordent aux programmes. Grâce à ce module, les administrateurs peuvent regrouper les privilèges Linux dans des rôles et les donner à leurs utilisateurs. Pour des raisons de sécurité, les utilisateurs n’obtiennent pas les rôles attribués par défaut, ils doivent les activer à l’aide de la commande sr (changer de rôle).
Cependant, la première version du RAR ne fournissait pas à l’administrateur la possibilité de connaître l’ensemble des privilèges qui sont demandés par un programme. Cette deuxième version ajoute l’outil capable qui permet à l’administrateur de disposer de cette information. Nous pensons que cet outil va largement contribuer à l’adoption de RootAsRole.
Cher journal,
Je ne t’écris pas aujourd’hui pour te parler de bière, mais pour te parler d’une faille dans sudo. A priori, elle est assez grave, puisqu’elle permet à un utilisateur qui ne peut pas lancer de commande en tant que root à outrepasser cette restriction en passant le userid −1 ou 4 294 967 295. Ceci veut dire que la commande suivante:
sudo -u#-1 id -u
Renvoie 0. Cependant, cela arrive pour des cas de configuration spécifique. Il faut (…)
Nous proposons un module qui permet de se passer des commandes su
et sudo
. L’avantage de notre module est qu’il permet de contrôler la liste des privilèges donnés aux programmes.
Traditionnellement, l’administration des systèmes GNU/Linux repose sur l’existence d’un seul utilisateur puissant (appelé super‐utilisateur) qui détient à lui seul la liste complète des privilèges du système. Cette vision a été critiquée car tous les programmes exécutés dans le contexte du super‐utilisateur obtiennent beaucoup plus de privilèges qu’ils n’en ont besoin. Par exemple, tcpdump
demande uniquement le privilège cap_net_raw
pour s’exécuter. Cependant, en l’exécutant dans le contexte de super‐utilisateur, tcpdump
obtient la liste complète des privilèges du système. Ainsi, l’approche traditionnelle de l’administration GNU/Linux rompt le principe du moindre privilège, qui garantit qu’un processus doit juste avoir les privilèges nécessaires pour effectuer son travail. Un attaquant pourrait exploiter les vulnérabilités de tcpdump
afin de compromettre la sécurité du système.
Il existe cependant une autre voie, non officielle, mais intégrée au noyau Linux depuis 1998…
Bonjour.
Utilisateur (pas administrateur système) aujourd'hui avertis de système GNU/Linux, j'ai monté une petite machine uniquement en ligne de commande (pour l'exercice, mais aussi car c'est bien suffisant pour ce que je veux en faire). Mais si l'utilisation ne me pose pas de difficultés, un problème reste en suspend :
Comment fait un utilisateur pour demander l'arrêt de la machine en ligne de commande ?
Quelle est la «bonne» méthode ?
Ou en tout cas celle qui s'éloignera le moins d'une utilisation (…)
Bonjour,
Je souhaite rajouter mon user TEST dans un groupe pour qu'il puisse redémarrer le service "systemctl".
On m'a parlé de /etc/sudoers
Pouvez-vous m'aider ?
Merci.
Bonjour,
j'aimerai modifier le mot de passe sudo le problème c'est qu'a chaque fois que j'édite le grub ou le sudoers il se modifie. en gros il réecrit le sudoers et tout ce qu'on a pu modifier dans le grub.
Cordialement Rémi
Une vulnérabilité vient d'être trouvé dans l'utilitaire sudo. Elle est présente dans la fonction sudo_debug
où un appelle à getprogname()
est effectué. Or le nom de l’exécutable étant contrôlé par l'utilisateur, on peut induire un comportement non voulu.
Les versions concernées sont les versions 1.8.0 à 1.8.3p1. La version 1.8.3p2 corrige la faille.
Plus de détails ici : http://seclists.org/fulldisclosure/2012/Jan/att-590/advisory_sudo.txt
Je continue mon exploration de ma nouvelle machine, et j'ai (dès le départ) profité de Compiz pour agrémenter l'expérience utilisateur. Ce que j'aime dans Compiz c'est le placement des fenêtres sur la moitié droite et la moitié gauche en un raccourci clavier, le cube avec les engrenages, et les fenêtres qui se déforment. C'est gadget, sauf le placement. (…)
Hello tout le monde.
Encore une fois, une question de responsabilité.
Cette fois-ci, le big boss me demande les mots de passes admin. Or, si je lui donne, il faut que je puisse prouver que je le lui ai donné, et qu'il y a donc plusieurs responsable en cas de pépins sur les machines.
Est ce que vous auriez sous la main un modèle qui serait adapté à cette situation, et qui stipulerait que je ne serai plus responsable de (…)