De l'utilité du "-"
Dans la commande su
Système et matériels / Administration système
Papoteur Membre non connecté
-
- Voir le profil du membre Papoteur
- Inscrit le : 03/10/2011
- Groupes :
-
Modérateur
-
Équipe Mageia
-
Administrateur
-
Forgeron
Je tombe sur ce rapport de bogue : https://bugs.mageia.org/show_bug.cgi?id=27580
L'utilisateur a exécuté une commande de nettoyage pour enlever les rpm de langues et de matériel inutilisés. Pour cela, il a ouvert une console et est devenu "root" par la commande su. Pas sûr que la perte de la basse rpm soit due à cette manoeuvre, mais au moins certains messages d'erreurs le sont.
Donc, il faut que nous recommandions systématiquement d'utiliser
Code BASH :
su -au lieu de su tout court.
[Complément]
Voici ma traduction de la page de man concernant l'option:
Man :
-, -l, --login
Démarre le shell avec un environnement similaire à celui d'un login réel:
- efface toutes les variables d'environnement sauf TERM et les variables désignées par --whitelist-environ‐
ment
- initialise les variables d'environnement HOME, SHELL, USER, LOGNAME, et PATH
- se place dans le répertoire de l'utilisateur ciblé
- met argv[0] du shell à '-' pour faire du shell un shell de connexion
Démarre le shell avec un environnement similaire à celui d'un login réel:
- efface toutes les variables d'environnement sauf TERM et les variables désignées par --whitelist-environ‐
ment
- initialise les variables d'environnement HOME, SHELL, USER, LOGNAME, et PATH
- se place dans le répertoire de l'utilisateur ciblé
- met argv[0] du shell à '-' pour faire du shell un shell de connexion
Édité par Papoteur Le 09/11/2020 à 09h16
funix Membre non connecté
-
- Voir le profil du membre funix
- Inscrit le : 17/12/2012
- Site internet
- Groupes :
cmoifp Membre non connecté
user to root
et chuser
I would ask you to modify your template a tiny bit.
Please would you change it from "su -" to "/bin/su -"?
I am a computer security professional with decades working in penetration testing and investigating compromised systems.
The reason I am asking this is because I have seen (all too often) systems get compromised because people inherently trust how $PATH is set.
Even experienced systems administrators will make this mistake.
It is good practice to use a full pathname for any command that prompts for password (especially root password).
Giving users examples of good security practice will hopefully reduce system compromises.
Why? For any command that prompts for a password, using a full path is more secure (than just the command name).
A technique used by hackers is to exploit your trust that when you type su (or sudo) you believe you are running the real su (or sudo)
If a hacker can gain access to your account, then your $PATH can be modified to run a spoofed su (or sudo) which captures your typed password, prints an error message, and then execs the real su (or sudo).
The user thinks "Oh, I miss-typed the password! I'll type it again". And they do...
cmoifp Membre non connecté
arte-naki Membre non connecté
-
- Voir le profil du membre arte-naki
- Inscrit le : 03/11/2020
cmoifp :
If a hacker can gain access to your account, then your $PATH can be modified to run a spoofed su (or sudo) which captures your typed password, prints an error message, and then execs the real su (or sudo)
If a hacker can gain access to your account, then your $PATH can be modified to run a spoofed su (or sudo) which captures your typed password, prints an error message, and then execs the real su (or sudo)
C'est vrai. Curieusement, exécuter des exécutables en tant que root avec sudo n'est autorisé qu'à partir de /usr/bin. Dans Ubuntu et Debian /usr/bin et /usr/local/bin.
secure_path est défini dans /etc/sudoers
Cependant, il est facile de remplacer le binaire sudo dans le PATH local avant d'obtenir les privilèges root.
-----
That's true. Curiously, running executables as root with sudo is only allowed from /usr/bin. In Ubuntu and Debian /usr/bin and /usr/local/bin.
secure_path is set in /etc/sudoers
However, it is easy to override sudo binary in the local PATH before gaining root privileges.
nmrk.n Membre non connecté
-
- Voir le profil du membre nmrk.n
- Inscrit le : 20/04/2018
- Site internet
- Groupes :
-
Banni
cmoifp :
Un peu dans le même rapport suite à la création des modèles
Caché :
user to root
et chuser
I would ask you to modify your template a tiny bit.
Please would you change it from "su -" to "/bin/su -"?
I am a computer security professional with decades working in penetration testing and investigating compromised systems.
The reason I am asking this is because I have seen (all too often) systems get compromised because people inherently trust how $PATH is set.
Even experienced systems administrators will make this mistake.
It is good practice to use a full pathname for any command that prompts for password (especially root password).
Giving users examples of good security practice will hopefully reduce system compromises.
Why? For any command that prompts for a password, using a full path is more secure (than just the command name).
A technique used by hackers is to exploit your trust that when you type su (or sudo) you believe you are running the real su (or sudo)
If a hacker can gain access to your account, then your $PATH can be modified to run a spoofed su (or sudo) which captures your typed password, prints an error message, and then execs the real su (or sudo).
The user thinks "Oh, I miss-typed the password! I'll type it again". And they do...
user to root
et chuser
I would ask you to modify your template a tiny bit.
Please would you change it from "su -" to "/bin/su -"?
I am a computer security professional with decades working in penetration testing and investigating compromised systems.
The reason I am asking this is because I have seen (all too often) systems get compromised because people inherently trust how $PATH is set.
Even experienced systems administrators will make this mistake.
It is good practice to use a full pathname for any command that prompts for password (especially root password).
Giving users examples of good security practice will hopefully reduce system compromises.
Why? For any command that prompts for a password, using a full path is more secure (than just the command name).
A technique used by hackers is to exploit your trust that when you type su (or sudo) you believe you are running the real su (or sudo)
If a hacker can gain access to your account, then your $PATH can be modified to run a spoofed su (or sudo) which captures your typed password, prints an error message, and then execs the real su (or sudo).
The user thinks "Oh, I miss-typed the password! I'll type it again". And they do...
Je vous demande de modifier un peu votre modèle.
Pourriez-vous le changer de "su -" à "/bin/su -" ?
Je suis un professionnel de la sécurité informatique qui travaille depuis des décennies dans le domaine des tests d'intrusion et des enquêtes sur les systèmes compromis.
La raison pour laquelle je vous demande cela est que j'ai vu (trop souvent) des systèmes être compromis parce que les gens font confiance à la façon dont $PATH est paramétré.
Même les administrateurs de systèmes expérimentés commettent cette erreur.
Il est bon d'utiliser un nom de chemin complet pour toute commande qui demande un mot de passe (en particulier le mot de passe de root).
En donnant aux utilisateurs des exemples de bonnes pratiques de sécurité, on espère réduire les risques de compromission du système.
Pourquoi ? Pour toute commande qui demande un mot de passe, l'utilisation d'un chemin d'accès complet est plus sûre (que le seul nom de la commande).
Une technique utilisée par les pirates consiste à exploiter votre confiance dans le fait que lorsque vous tapez su (ou sudo), vous pensez que vous exécutez le vrai su (ou sudo)
Si un pirate informatique peut accéder à votre compte, votre $PATH peut être modifié pour exécuter un su (ou sudo) usurpé qui capture votre mot de passe tapé, imprime un message d'erreur, puis exécute le vrai su (ou sudo).
L'utilisateur pense alors "Oh, j'ai mal tapé le mot de passe ! Je vais le retaper". Et c'est ce qu'il fait...
Édité par nmrk.n Le 09/11/2020 à 14h48
choucroot Membre non connecté
-
- Voir le profil du membre choucroot
- Inscrit le : 07/08/2015
- Groupes :
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie