En utilisant des clefs ssh, il est possible de restreindre les
commandes qu'il est possible de lancer en spécifiant la commande
souhaitée dans le fichier authorized_keys.
Cependant, ce n'est pas un moyen très fin de restreindre les
possibilités vu que si l'on spécifie un attribut "command" dans le
authorized_keys, la commande fournie par l'utilisateur est ignorée et
c'est la commande du authorized_keys qui est utilisée.
Ainsi, il n'est pas possible d'autoriser par exemple des choses de ce
genre :
- "ls *" pour autoriser la commande ls suivie de n'importe quel
argument
- "tar zcvf - *" pour autoriser de sauvegarder n'importe quoi
Un paliatif consisterait à remplacer le shell de l'utilisateur par un
programme qui vérifierait si la commande fournie répond à une
politique (par exemple, qu'elle matche une regexp). Pas très compliqué
à faire, mais est-ce que cela existe déjà ?
--
I WILL NOT DRIVE THE PRINCIPAL'S CAR
I WILL NOT DRIVE THE PRINCIPAL'S CAR
I WILL NOT DRIVE THE PRINCIPAL'S CAR
-+- Bart Simpson on chalkboard in episode 7F06
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc
Vincent Bernat wrote:
Un paliatif consisterait à remplacer le shell de l'utilisateur par un programme qui vérifierait si la commande fournie répond à une politique (par exemple, qu'elle matche une regexp). Pas très compliqué à faire, mais est-ce que cela existe déjà ?
C'est un peu le principe du restricted shell (de nombreux shells ont un mode restricted, il faut regarder leur doc). Sinon peut-être quelque chose utilisant sudo. Ou des ACLs. (je n'ai pas lu le post en détails)
Vincent Bernat wrote:
Un paliatif consisterait à remplacer le shell de l'utilisateur par un
programme qui vérifierait si la commande fournie répond à une
politique (par exemple, qu'elle matche une regexp). Pas très compliqué
à faire, mais est-ce que cela existe déjà ?
C'est un peu le principe du restricted shell (de nombreux shells ont un
mode restricted, il faut regarder leur doc). Sinon peut-être quelque
chose utilisant sudo. Ou des ACLs. (je n'ai pas lu le post en détails)
Un paliatif consisterait à remplacer le shell de l'utilisateur par un programme qui vérifierait si la commande fournie répond à une politique (par exemple, qu'elle matche une regexp). Pas très compliqué à faire, mais est-ce que cela existe déjà ?
C'est un peu le principe du restricted shell (de nombreux shells ont un mode restricted, il faut regarder leur doc). Sinon peut-être quelque chose utilisant sudo. Ou des ACLs. (je n'ai pas lu le post en détails)
Vincent Bernat
OoO La nuit ayant déjà recouvert d'encre ce jour du samedi 30 décembre 2006, vers 23:54, Marc disait:
Un paliatif consisterait à remplacer le shell de l'utilisateur par un programme qui vérifierait si la commande fournie répond à une politique (par exemple, qu'elle matche une regexp). Pas très compliqué à faire, mais est-ce que cela existe déjà ?
C'est un peu le principe du restricted shell (de nombreux shells ont un mode restricted, il faut regarder leur doc). Sinon peut-être quelque chose utilisant sudo. Ou des ACLs. (je n'ai pas lu le post en détails)
C'est en effet une idée : donner un restricted shell (comme le mode restricted dans zsh) et placer un fichier de configuration qui met PATH à "." (ou le répertoire des commandes autorisées) et ainsi n'autoriser que les commandes en question.
Mais je retombe sur mon problème avec ssh : je peux autoriser ainsi une commande fixe (ou plusieurs commandes fixes), mais pas quelque chose du genre "ls *" où "*" est un nom de fichier quelconque. Bien sûr, la commande que je peux autoriser peut vérifier que les arguments qui lui sont passés correspondent à une politique de sécurité. Ainsi, au lieu d'invoquer "ls machin", j'invoque "checkcommand ls machin". Mais je reviens au point de départ (l'existence de la commande checkcommand) et le restricted shell ne m'aura servi à rien. :)
Si je demande si une telle commande existe, c'est que ce n'est pas évident à faire. ssh invoque un shell sur la machine distante et la commande est donc interprétée par le shell.
Si par exemple, je veux autoriser uniquement "tar zcvf - *" avec * n'importe quoi, l'utilisateur pourrait par exemple invoquer "tar zcvf - /dev/null ; touch /tmp/toto". Une solution serait d'être plus restrictif avec : "tar zcvf - %f" où %f est remplacé par un fichier qui existe. Et encore, le fichier "; touch /tmp/toto" peut très bien exister et la commande ne ferait toujours pas ce que l'on attend d'elle... -- panic ("No CPUs found. System halted.n"); 2.4.3 linux/arch/parisc/kernel/setup.c
OoO La nuit ayant déjà recouvert d'encre ce jour du samedi 30 décembre
2006, vers 23:54, Marc <marc.glisse@gmail.com> disait:
Un paliatif consisterait à remplacer le shell de l'utilisateur par un
programme qui vérifierait si la commande fournie répond à une
politique (par exemple, qu'elle matche une regexp). Pas très compliqué
à faire, mais est-ce que cela existe déjà ?
C'est un peu le principe du restricted shell (de nombreux shells ont un
mode restricted, il faut regarder leur doc). Sinon peut-être quelque
chose utilisant sudo. Ou des ACLs. (je n'ai pas lu le post en
détails)
C'est en effet une idée : donner un restricted shell (comme le mode
restricted dans zsh) et placer un fichier de configuration qui met
PATH à "." (ou le répertoire des commandes autorisées) et ainsi
n'autoriser que les commandes en question.
Mais je retombe sur mon problème avec ssh : je peux autoriser ainsi
une commande fixe (ou plusieurs commandes fixes), mais pas quelque
chose du genre "ls *" où "*" est un nom de fichier quelconque. Bien
sûr, la commande que je peux autoriser peut vérifier que les arguments
qui lui sont passés correspondent à une politique de sécurité. Ainsi,
au lieu d'invoquer "ls machin", j'invoque "checkcommand ls
machin". Mais je reviens au point de départ (l'existence de la
commande checkcommand) et le restricted shell ne m'aura servi à
rien. :)
Si je demande si une telle commande existe, c'est que ce n'est pas
évident à faire. ssh invoque un shell sur la machine distante et la
commande est donc interprétée par le shell.
Si par exemple, je veux autoriser uniquement "tar zcvf - *" avec *
n'importe quoi, l'utilisateur pourrait par exemple invoquer "tar zcvf
- /dev/null ; touch /tmp/toto". Une solution serait d'être plus
restrictif avec : "tar zcvf - %f" où %f est remplacé par un fichier
qui existe. Et encore, le fichier "; touch /tmp/toto" peut très bien
exister et la commande ne ferait toujours pas ce que l'on attend
d'elle...
--
panic ("No CPUs found. System halted.n");
2.4.3 linux/arch/parisc/kernel/setup.c
OoO La nuit ayant déjà recouvert d'encre ce jour du samedi 30 décembre 2006, vers 23:54, Marc disait:
Un paliatif consisterait à remplacer le shell de l'utilisateur par un programme qui vérifierait si la commande fournie répond à une politique (par exemple, qu'elle matche une regexp). Pas très compliqué à faire, mais est-ce que cela existe déjà ?
C'est un peu le principe du restricted shell (de nombreux shells ont un mode restricted, il faut regarder leur doc). Sinon peut-être quelque chose utilisant sudo. Ou des ACLs. (je n'ai pas lu le post en détails)
C'est en effet une idée : donner un restricted shell (comme le mode restricted dans zsh) et placer un fichier de configuration qui met PATH à "." (ou le répertoire des commandes autorisées) et ainsi n'autoriser que les commandes en question.
Mais je retombe sur mon problème avec ssh : je peux autoriser ainsi une commande fixe (ou plusieurs commandes fixes), mais pas quelque chose du genre "ls *" où "*" est un nom de fichier quelconque. Bien sûr, la commande que je peux autoriser peut vérifier que les arguments qui lui sont passés correspondent à une politique de sécurité. Ainsi, au lieu d'invoquer "ls machin", j'invoque "checkcommand ls machin". Mais je reviens au point de départ (l'existence de la commande checkcommand) et le restricted shell ne m'aura servi à rien. :)
Si je demande si une telle commande existe, c'est que ce n'est pas évident à faire. ssh invoque un shell sur la machine distante et la commande est donc interprétée par le shell.
Si par exemple, je veux autoriser uniquement "tar zcvf - *" avec * n'importe quoi, l'utilisateur pourrait par exemple invoquer "tar zcvf - /dev/null ; touch /tmp/toto". Une solution serait d'être plus restrictif avec : "tar zcvf - %f" où %f est remplacé par un fichier qui existe. Et encore, le fichier "; touch /tmp/toto" peut très bien exister et la commande ne ferait toujours pas ce que l'on attend d'elle... -- panic ("No CPUs found. System halted.n"); 2.4.3 linux/arch/parisc/kernel/setup.c
Marc
Vincent Bernat wrote:
au lieu d'invoquer "ls machin", j'invoque "checkcommand ls machin". Mais je reviens au point de départ (l'existence de la commande checkcommand) et le restricted shell ne m'aura servi à rien. :)
Je citais 2 autres possibilités dans ma réponse, dont une qui ressemble un peu à checkcommand...
Vincent Bernat wrote:
au lieu d'invoquer "ls machin", j'invoque "checkcommand ls
machin". Mais je reviens au point de départ (l'existence de la
commande checkcommand) et le restricted shell ne m'aura servi à
rien. :)
Je citais 2 autres possibilités dans ma réponse, dont une qui ressemble
un peu à checkcommand...
au lieu d'invoquer "ls machin", j'invoque "checkcommand ls machin". Mais je reviens au point de départ (l'existence de la commande checkcommand) et le restricted shell ne m'aura servi à rien. :)
Je citais 2 autres possibilités dans ma réponse, dont une qui ressemble un peu à checkcommand...
Vincent Bernat
OoO En cette fin de matinée radieuse du dimanche 31 décembre 2006, vers 11:51, Marc disait:
au lieu d'invoquer "ls machin", j'invoque "checkcommand ls machin". Mais je reviens au point de départ (l'existence de la commande checkcommand) et le restricted shell ne m'aura servi à rien. :)
Je citais 2 autres possibilités dans ma réponse, dont une qui ressemble un peu à checkcommand...
C'est vrai. Un restricted shell qui n'autorise que sudo qui autorise à son tour une commande. -- Don't use conditional branches as a substitute for a logical expression. - The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du dimanche 31 décembre 2006,
vers 11:51, Marc <marc.glisse@gmail.com> disait:
au lieu d'invoquer "ls machin", j'invoque "checkcommand ls
machin". Mais je reviens au point de départ (l'existence de la
commande checkcommand) et le restricted shell ne m'aura servi à
rien. :)
Je citais 2 autres possibilités dans ma réponse, dont une qui ressemble
un peu à checkcommand...
C'est vrai. Un restricted shell qui n'autorise que sudo qui autorise à
son tour une commande.
--
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)
OoO En cette fin de matinée radieuse du dimanche 31 décembre 2006, vers 11:51, Marc disait:
au lieu d'invoquer "ls machin", j'invoque "checkcommand ls machin". Mais je reviens au point de départ (l'existence de la commande checkcommand) et le restricted shell ne m'aura servi à rien. :)
Je citais 2 autres possibilités dans ma réponse, dont une qui ressemble un peu à checkcommand...
C'est vrai. Un restricted shell qui n'autorise que sudo qui autorise à son tour une commande. -- Don't use conditional branches as a substitute for a logical expression. - The Elements of Programming Style (Kernighan & Plauger)
Nicolas George
wrote in message :
Ayant eu le même problème à cette époque (à savoir permettre le lancement de 1 ou plusieurs commandes avec une liste non connues d'options), je n'ai pas réussi à coder ça dans le fichier de conf. J'arrivais bien à interdire les ; && || ^ ` mais jamais le ctrl-v ctrl-entrée accepté par le shell, qui permet aussi de lancer une commande quelconque ensuite.
sudo n'invoque pas de shell pour exécuter la commande qui lui est passée, donc protéger contre les caractères spéciaux du shell ne sert à rien.
Par exemple, si tu autorises la commande true suivie de n'importe quoi, deux possibilités :
sudo true ; vim /etc/passwd
Le ; agit en amont de sudo, et le vim est exécuté sans droits particuliers.
sudo true ; vim /etc/passwd
sudo exécute true, avec trois arguments : ;, vim et /etc/group. true n'a que faire de ces arguments, et aucun vim n'est exécuté.
Le seul risque survient si la commande autorisée par sudo va elle-même invoquer un shell.
fabrice.gonton@gmail.com wrote in message
<1167842829.006037.92220@h40g2000cwb.googlegroups.com>:
Ayant eu le même problème à cette époque (à savoir permettre le
lancement de 1 ou plusieurs commandes avec une liste non connues
d'options), je n'ai pas réussi à coder ça dans le fichier de conf.
J'arrivais bien à interdire les ; && || ^ ` mais jamais le
ctrl-v ctrl-entrée accepté par le shell, qui permet aussi de lancer
une commande quelconque ensuite.
sudo n'invoque pas de shell pour exécuter la commande qui lui est passée,
donc protéger contre les caractères spéciaux du shell ne sert à rien.
Par exemple, si tu autorises la commande true suivie de n'importe quoi, deux
possibilités :
sudo true ; vim /etc/passwd
Le ; agit en amont de sudo, et le vim est exécuté sans droits particuliers.
sudo true ; vim /etc/passwd
sudo exécute true, avec trois arguments : ;, vim et /etc/group. true n'a que
faire de ces arguments, et aucun vim n'est exécuté.
Le seul risque survient si la commande autorisée par sudo va elle-même
invoquer un shell.
Ayant eu le même problème à cette époque (à savoir permettre le lancement de 1 ou plusieurs commandes avec une liste non connues d'options), je n'ai pas réussi à coder ça dans le fichier de conf. J'arrivais bien à interdire les ; && || ^ ` mais jamais le ctrl-v ctrl-entrée accepté par le shell, qui permet aussi de lancer une commande quelconque ensuite.
sudo n'invoque pas de shell pour exécuter la commande qui lui est passée, donc protéger contre les caractères spéciaux du shell ne sert à rien.
Par exemple, si tu autorises la commande true suivie de n'importe quoi, deux possibilités :
sudo true ; vim /etc/passwd
Le ; agit en amont de sudo, et le vim est exécuté sans droits particuliers.
sudo true ; vim /etc/passwd
sudo exécute true, avec trois arguments : ;, vim et /etc/group. true n'a que faire de ces arguments, et aucun vim n'est exécuté.
Le seul risque survient si la commande autorisée par sudo va elle-même invoquer un shell.
