Linux.general : compte utilisateur

Posté par zigfrid75 () le 26 mars 2008

bonjour a tous, question a 2 balles. est il possible de n'autoriser a un user que d'utiliser certainne commande et seulement ces commandes. pour etre plus precis je voudrais que ce user n'ai le droit que de lancer un script et rien d'autre. pas de mkdir, pas de ls enfin juste lancer le script. est ce possible ? si oui comment proceder ?

> Lire le message (14 commentaires, moyenne: 1,9).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Avec su

Posté par Obsidian () le 26/03/2008 à 13:08. (lien). Évalué à 4.

Question à 2,50 balles. Ton utilisateur est-il réel et doit-il pouvoir se logguer quand même ?

Si non, tu mets soit un setuid bit sur l'exécutable si c'en est un, soit tu passes par su si c'est vraiment un script.

Si oui, tu définis le script ou l'exécutable comme shell de l'utilisateur. Il sera automatiquement exécuté à la connexion à l'exclusion de tout le reste et la session se referma avec lui.

Avec ssh

Posté par lom (page perso, ) le 26/03/2008 à 14:21. (lien). Évalué à 0.

Truc que j'avais vu il ya quelques temps, mais je n'arrive pas a retrouver les references... Juste une piste donc.

Avec ssh, tu peux forcer le shell d'un utilisateur a la connexion. Par consequent, si au lieu de forcer un shell standard, tu donnes le chemin de ton script a la place et ferme la connexion, seul ce script sera execute.

Maintenant a toi de retrouver comment faire, moi je ne sais pas :o)

[^]Re: Avec ssh

Posté par Gérald (page perso, ) le 26/03/2008 à 14:42. (lien). Évalué à 0.

Avec ssh, tu peux forcer le shell d'un utilisateur a la connexion.

Aucune trace de ça dans le man 5 sshd_config.

Le seul truc qui pourrait s'approcher de ce que tu décris serait de
forcer la variable d'environnement SHELL (voir AcceptEnv dans man 5 sshd_config), mais :

1/ je suis pas sur que ça outrepasse vraiment le shell par défaut de l'utilisateur.
2/ Ce serait plus à l'initiative de l'utilisateur qui se connecte, et faire confiance à l'utilisateur c'est aller dans le mur :)

Par contre, changer le shell de l'utilisateur se fait très bien à coup de chsh en tant que root.
Donc à priori tu peux très bien faire:
chsh -s <chemin du script> <user>

Toutefois cette modification sera globale au système, et non juste pour les connexions ssh.
- [^]Re: Avec ssh
  
  Posté par lom (page perso, ) le 26/03/2008 à 16:10. (lien). Évalué à 2.
  En cherchant un peu plus...
  man sshd, section LOGIN PROCESS
  => ssh execute le fichier ~/.ssh/rc s'il existe. Il suffit donc de mettre dans ce fichier:
  
  /path/vers/le/script/kivabien
  exit
  
  et zouplaboum, la connexion se fermera apres execution du script
  C'est vrai que je me suis plante, ce n'est pas le shell par defaut qui est change...
  - [^]Re: Avec ssh
    
    Posté par Gérald (page perso, ) le 26/03/2008 à 17:29. (lien). Évalué à 2.
    
    et zouplaboum, la connexion se fermera apres execution du script
    C'est vrai que je me suis plante, ce n'est pas le shell par defaut qui est change...
    
    Ok, j'ai matté la page de man en question, par contre je suis pas sur que le comportement que tu décris soit bon.
    En effet, je lis:
    
    7. Changes to user's home directory.
    
    8. If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists,
    runs it; otherwise runs xauth. The ``rc'' files are given the
    X11 authentication protocol and cookie in standard input.
    
    9. Runs user's shell or command.
    
    Je vois plus le point 8. comme une étape intermédiaire te permettant d'éxecuter des actions avant de lancer le shell.
    Le lancement du shell ne semble pas avoir pour condition la (non) execution du script.
    Donc, à mon avis, dans ton exemple, le shell de l'utilisateur sera lancé après le script.
    On doit toujours pouvoir gruger en mettant /bin/true comme shell à l'utilisateur.
    
    Après, j'pense que pour être sur il faudrait tester et j'avoue avoir la flemme :)
    - [^]Re: Avec ssh
      
      Posté par lom (page perso, ) le 27/03/2008 à 10:03. (lien). Évalué à 2.
      Tu a jete l'esprit dans mon trouble...
      
      Donc avec un ~/.ssh/rc contenant
      fortune exit
      et en me logant via ssh, j'ai bien une jolie fortune et la connexion ferme aussitot. Ca permet donc de ne pas changer le shell par defaut.
      - [^]Re: Avec ssh
        
        Posté par Etienne () le 27/03/2008 à 10:55. (lien). Évalué à 2.
        Le serveur SSH va exécuter fortune mais ça ne ferme pas la connexion. Le script ~/.ssh/rc est exécuté mais pas "sourcé" par ton shell. Ton exit va juste te faire sortir du script rc, ensuite la connection ssh va continuer.
        Par contre je pense qu'en mettant comme shell /bin/false (ou /sbin/nologin sur certaines distributions), tu va exécuter le script rc puis un shell qui quitte tout de suite.
        
        Etienne
        
        [^]Re: Avec ssh
        
        Posté par lom (page perso, ) le 27/03/2008 à 11:31. (lien). Évalué à 2.
        Ca a pourtant ete teste et approuve par moi meme ce matin.
        La connexion ssh s'arrete, alors que je peux me connecter sans souci (ie sans changer le shell par defaut) en dehors de ssh.
        Apres, je suis peut etre dans un cas special, mais j'en doute.
        
        [^]Re: Avec ssh
        
        Posté par Gérald (page perso, ) le 27/03/2008 à 11:35. (lien). Évalué à 1.
        Bein testé et desapprouvé à l'instant:
        [binarym@gco]:~% echo "uname -a\nexit\n" > .ssh/rc [binarym@gco]:~% ssh localhost binarym@localhost's password: Linux gco 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Thu Mar 27 12:31:21 2008 from localhost Linux gco 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 GNU/Linux [binarym@gco]:~% exit Connection to localhost closed.
        
        [^]Re: Avec ssh
        
        Posté par syntaxerror () le 27/03/2008 à 18:35. (lien). Évalué à 1.
        man sshd
        /authorized
        
        à condition que l'utilisateur s'authentifie par clef, on peut forcer la commande à exécuter dans ~/.ssh/authorized_keys
        (exemple d'utilisation, uucp sur ssh)

Shell restrictif

Posté par Gérald (page perso, ) le 26/03/2008 à 14:22. (lien). Évalué à 5.

Il est difficile de gérer ce genre de permission au niveau des permissions du système de fichiers.

Ca doit pouvoir se faire à coup de selinux et consors, mais c'est certainement bien compliqué pour peu de chose.

La solution vers laquelle je m'orienterai pour ma part serait un shell restrictif qui autorise ou non l'execution des commandes en question.
Ca se code très bien en shell.
Exemple:

[binarym@gco]:~% grep test /etc/passwd 15:18 test:x:1001:1001::/home/test:/tmp/rshell.sh [binarym@gco]:~% cat /tmp/rshell.sh #!/bin/sh do_exit=0 while (( ! $do_exit)) ; do echo "exit or uname ?" read cmd; if [ "$cmd" != "exit" ] && [ "$cmd" != "uname" ] ; then echo "$cmd not allowed"; elif [ "$cmd" == "exit" ] ; then do_exit=1; else uname; fi; done [binarym@gco]:~% su - test Password: Pas de répertoire, connexion avec HOME=/ exit or uname ? uname Linux exit or uname ? ls ls not allowed exit or uname ? uname -a uname -a not allowed exit or uname ? uname | ls uname | ls not allowed exit or uname ? exit

Voilà.

[^]rbash

Posté par daggett () le 28/03/2008 à 14:35. (lien). Évalué à 2.
y a un truc fait pour ça, c'est rbash (restricted bash). man rbash.

C'est un vrai bash complet, mais qui interdit plein de choses en mode interactif (mais pas en mode script). Entre autres, de changer de répertoire, et de lancer des programmes avec un chemin explicite.
Si le bashrc positionne des PATH et des alias qui vont bien, alors normalement il ne laissera à l'utilisateur que le choix de lancer les applis que tu prédéfinis.

Après il suffit de mettre rbash au lieu de bash comme shell par défaut de ce compte.
- [^]Re: rbash
  
  Posté par Gérald (page perso, ) le 28/03/2008 à 17:29. (lien). Évalué à 1.
  Bien vu. Je connaissais pas et un apt-cache search restricted shell ne m'a rien donné sur ma testing...

sans ssh, sans shell special...

Posté par NeoX () le 26/03/2008 à 18:07. (lien). Évalué à 2.

il suffit de dire que le shell de l'utilisateur (dans le /etc/password)
n'est plus /bin/bash (/bin/sh, /bin/zsh...)

mais /usr/local/bin/ton_programme

l'utilisateur se log en ssh/telnet => ca lance le programme
l'utilisateur ouvre un terminal => ca lance le programme (enfin je crois)

pour que ce programme se lance automatique avec quand cet utilisateur se log avec X, il me semble que ca se joue dans le .Xsession

si c'est pour faire un programme qui se lance uniquement en tant qu'un utilisateur (un daemon/service/serveur) alors le SUID doit etre la solution.

--
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux

Revenir en haut de page || Retourner aux forums || Retourner au forum Linux.general

Linux.general : compte utilisateur

Avec su

Avec ssh

[^]Re: Avec ssh

[^]Re: Avec ssh

[^]Re: Avec ssh

[^]Re: Avec ssh

[^]Re: Avec ssh

[^]Re: Avec ssh

[^]Re: Avec ssh

[^]Re: Avec ssh

Shell restrictif

[^]rbash

[^]Re: rbash

sans ssh, sans shell special...