Cacher le secret de paramètre de ligne de commande sous Unix
J'ai un script qui se lance à l'intérieur de lui-même une commande avec un paramètre qui est un secret. Par exemple:
#!/bin/bash
command-name secret
Lors de l'exécution de la commande, je peux lire à travers ps -ef | grep command-name
qui est le secret.
Est-il un moyen de cacher le secret dans une manière que par ps -ef
, le paramètre de ligne de commande est brouillée?
- La commande accepte le secret argument par le biais d'un fichier d'entrée ou des cours d'eau?
- Notez que le script lui-même est lisible, de sorte que le secret est visible à toute personne intéressée à le trouver. Pour un utilisateur d'être en mesure d'exécuter un shell script, le script doit être lisible ou vous devez utiliser un programme SUID pour exécuter une copie protégée de l'script, ou d'autres semblables à des contorsions.
- Voici une bonne réponse: modifier /proc/PID/cmdline à l'aide d'un tour de Scott James Remnant netsplit.com/hiding-arguments-from-ps
Vous devez vous connecter pour publier un commentaire.
Si le secret ne change pas entre les exécutions, à l'aide d'un fichier de configuration,
".appsecrets"
. Définir les autorisations sur le fichier en lecture seule par le propriétaire. À l'intérieur du fichier de définir une variable d'environnement pour le secret. Le fichier doit être dans le répertoire home de l'utilisateur qui exécute la commande.Charger le fichier de configuration de sorte que la variable d'environnement est défini.
Ce que j'ai vu faire:
1)
echo $SECRET | command
fonctionne si la commande demande le mot de passe à partir de stdin ET si "echo" est un builtin de votre coquille. Nous avons été à l'aide de Korn.
2)
password=$ENV{"SECRET"};
fonctionne si vous avez le contrôle du code (par exemple en perl ou en C++)
3)
. ./.app.config #sets the environment variables
isql -host [host] -user [user] -password <<SECRET
${SQLPASSWORD}
SECRET
si la commande peut accepter le secret de std-en. Une limitation est que le
<<
chaîne doit être le dernier argument à la commande. Cela peut être gênant si il y a un non-facultatif arg qui apparaît après le mot de passeL'avantage de cette approche est que vous pouvez les disposer de façon à le secret peut être caché dans la production. Utiliser le même nom de fichier dans la production, mais il sera dans le répertoire personnel du compte qui exécute la commande dans la production. Ensuite, vous pouvez verrouiller l'accès pour le plus grand secret, comme vous l'accès au compte root. Seules certaines personnes puissent " su "pour la prod compte à vue ou de garder le secret, tandis que les développeurs peuvent continuer à exécuter le programme, car ils utilisent leur propre".appsecret fichier dans son répertoire home.
Vous pouvez utiliser cette approche pour stocker des informations sécurisées pour n'importe quel nombre d'applications, aussi longtemps qu'ils utilisent différents noms de variables d'environnement pour leurs secrets.
(DE MANIÈRE ERRONÉE)
Une vieille méthode que j'ai vu les Administrateurs de bases de données était de définir SYBASE à
"/opt/././././././././././././././././././././././././././././././././././sybase/bin"
. De sorte que leur commandlines ont été si longtemps le ps tronquée. Mais en linux, je pense que vous pourriez être en mesure de détecter l'intégralité de la ligne de commande dans le répertoire /proc.ps
montre la version étendue de l'information.ps
tronquée"------ Avecps ww
il peut montrer plein de ligne de commandeTout d'abord, vous ne pouvez PAS masquer les arguments de ligne de commande. Ils seront toujours visibles via
ps aux
etcat /proc/$YOUR_PROCESS_PID/cmdline
au moment du lancement du programme (avant le programme a une chance de faire les changements d'exécution des arguments). La bonne nouvelle est que vous pouvez toujours avoir un secret, en utilisant les alternatives:Utiliser des variables d'environnement. Si votre programme ne peut les lire, faire ceci:
Utiliser l'entrée standard:
Utilisation temporaire descripteur de fichier:
Dans le dernier cas, votre programme sera lancé comme
myCommand /dev/fd/67
, où le contenu de/dev/fd/67
est votre secret (hello-neo
dans cet exemple).Dans toutes les approches décrites ci-dessus, méfiez-vous de laisser la commande dans la commande bash histoire (
~/.bash_history
). Vous pouvez éviter ce problème en exécutant la commande à partir d'un script (fichier), ou de manière interactive vous invite de mot de passe à chaque fois:ps -ef
:/xware/lib/EmbedThunderManager ******************************************
mysql -u root -p mypassword
montre quemysql -u root -px xxxxxxxxxx
dans les deuxtop
etps -ef
. Ce n'est pas lié à défilement ou de troncature.top
n'est pas le seul test que vous pouvez faire. Par exemple,mysql
pourrait avoir fourchue son propre processus avec les différents arguments de ligne de commande (en passant de mot de passe dans l'environnement à la place). Dans ce cas, les étrangers processus était encore en mesure d'intercepter le mot de passe, alors que mysql a commencé à courir, mais avant de la fourche elle-même. Même avec la réponse de @JorgeFuentesGonzálezLa seule façon de cacher votre secret argument de
ps
n'est pas de fournir le secret comme un argument. Une façon de le faire est de placer le secret dans un fichier, et de rediriger descripteur de fichier 3 pour lire le fichier, puis supprimer le fichier:Ce n'est pas tout à fait clair que c'est un moyen sûr pour sauvegarder le secret; la commande echo est un environnement intégré, donc il ne devrait pas figurer dans le 'ps' sortie (et de toute apparence serait éphémère). Une fois sur a très, très longtemps,
echo
n'a pas été intégré dans l' - en effet, sur MacOS X, il y a toujours un/bin/echo
, même si c'est intégré à tous les shells.Bien sûr, cela suppose que vous avez la source de
command
et peut le modifier pour lire le secret d'une pré-ouverture du descripteur de fichier au lieu de l'argument de ligne de commande. Si vous ne pouvez pas modifier la commande, vous êtes complètement bloqué - le 'ps' inscription sur la liste d'afficher les informations.Une autre astuce que vous pourriez tirer si vous êtes le propriétaire de commande: vous pouvez capturer l'argument de (secret), l'écrire sur un tuyau ou un fichier (qui est immédiatement déconnecté) pour vous-même, et puis re-exec commande sans que le secret de l'argument; la deuxième invocation sait que, puisque le secret est absent, il faut chercher là où la première invocation caché le secret. Le deuxième appel (moins secret) est ce qui apparaît dans le 'ps' sortie après le minuscule intervalle de cacher le secret. Pas aussi bon que d'avoir le secret de canal mis en place dès le début. Mais ceux-ci sont révélateurs de la durée à laquelle vous devez aller.
Zapping un argument de l'intérieur du programme - écrasement avec des zéros, par exemple - ne cache pas l'argument de 'ps'.
umask 077
avant l'écho pour s'assurer que seul l'utilisateur peut lire le fichier.La
expect
de la bibliothèque a été créée en partie pour ce genre de choses, de sorte que vous pouvez toujours fournir un mot de passe ou d'autres informations sensibles à un processus sans avoir à passer comme un argument. En supposant que, lorsque "secret" n'est pas donné, le programme vous demande de bien sûr.Je l'ai vu sur un autre post. C'est la façon la plus simple sous Linux.
Cela modifie la mémoire de la partie de ligne de commande que tous les autres programmes les voir.
Vous pouvez également modifier le nom du processus, mais seulement lorsque la lecture à partir de la ligne de commande. Des programmes comme
top
montrera le vrai nom du processus:N'oubliez pas de copie maximale
strlen(argv[0])
octets, sans doute parce que il n'y a plus d'espace alloué.Je pense que les arguments ne peuvent être trouvés dans la partie de la mémoire que nous modifions donc je pense que cela fonctionne comme un charme. Si quelqu'un sait quelque chose de précis à ce sujet, s'il vous plaît commentaire.
VasyaNovikov remarque: Le mot de passe peut encore être intercepté après que le programme a invoqué, mais avant il a commencé à faire les changements que vous avez décrit.
Il n'y a pas de façon facile. Jetez un oeil à cette question que j'ai posée tout à l'heure:
Masquer les arguments du ps
Est
command
votre propre programme? Vous pouvez essayer de chiffrer le secret et qui ont lecommand
déchiffrer avant de l'utiliser.Vous pouvez utiliser
LD_PRELOAD
d'avoir une bibliothèque de manipuler les arguments de ligne de commande de certains binaires dans le processus de binaire lui-même, oùps
ne pas le ramasser. Voir cette réponse de la mine sur le Serveur Faute pour plus de détails.Si le script est destiné à s'exécuter manuellement, le meilleur moyen est de le lire depuis l'entrée standard STDIN
read -s
qui n'a pas d'écho à l'entrée des caractères de sorte que vous ne devez utiliser stty avec des obus qui n'ont pas (zsh l'a aussi).ps
de sortie - mais la question est de savoir comment éviter que l'exposition.peut-être vous pouvez faire comme ceci:
Ici est une façon de cacher un secret dans une variable d'environnement de ps:
Dans le ps vous verrez quelque chose comme ceci:
Elastalert et Logstash sont des exemples de services qui peuvent les mots de passe d'accès via des variables d'environnement.