# [jail] problème de protection (résolu)

## loopx

Bonsoir, 

Cet après-midi, j'ai installé "jail" et me suis créé un environnement "chroot" avec le minimum requi : bash. Malgré la bien meilleur sécurité que jail m'apporte, je viens de remarquer un truc qui n'est pas très très cool ...

Déjà, de 1, l'environnement de chroot se trouve dans /var ...

Voici ce que un utilisateur en prison pourrait faire :

```
-jail-3.2$

!         ]]        break     command   dirs      elif      exec      fg        hash      jobs      popd      readonly  shopt     time      typeset   until

./        alias     builtin   compgen   disown    else      exit      fi        help      kill      printf    return    source    times     ulimit    wait

:         bash      caller    complete  do        enable    export    for       history   let       pushd     select    suspend   trap      umask     while

[         bg        case      continue  done      esac      false     function  if        local     pwd       set       test      true      unalias   {

[[        bind      cd        declare   echo      eval      fc        getopts   in        logout    read      shift     then      type      unset     }
```

bref, il peut faire du bash ... et il peut utiliser la redirection de flux ">". Je veux en venir au fait que ... même ainsi, je pourrais avoir de gros problème avec mon serveur ... si un petit c** se connecte et fait une boucle bash pour ecrire dans un fichier ... le proco monterais vite à 100% et /var serait full avec les conséquences que cela impliquerais ...

Pas très marrant donc, y aurait-il moyen d'éviter l'écriture ou mieux, retirer des commandes de bash, genre les boucles ?  :Very Happy:    ou alors, un "bash" spécial prisonier ?   :Laughing: 

----------

## truc

Bah tu peux lui mettre rbash comme shell par exemple, tu vas voir, c'esst très très limité...

----------

## geekounet

Quelque soit le shell que tu mettes, la moindre faille permettant une injection permettra à l'utilisateur de faire ce qu'il veut. De plus, un chroot (parce que ce "jail" sous Linux n'est que ça, ça n'est pas le vrai jail des BSD qui lui est vraiment sécurisé) n'apporte aucune securité (ce n'est pas fait pour ça, les développeurs le disent eux même), ya toujours accès à tous les processus tournant sur l'hote, ya toujours un accès complet aux interfaces réseaux. etc. Ça ne fait qu'isoler du FS, mais ça ne sécurise rien du tout.

Sinon un minimum à faire, c'est de mettre cet environnement chroot sur une partition à part, ainsi ça n'aura aucun impact sur le reste si jamais la partition se remplit.

----------

## loopx

 *geekounet wrote:*   

> Quelque soit le shell que tu mettes, la moindre faille permettant une injection permettra à l'utilisateur de faire ce qu'il veut. De plus, un chroot (parce que ce "jail" sous Linux n'est que ça, ça n'est pas le vrai jail des BSD qui lui est vraiment sécurisé) n'apporte aucune securité (ce n'est pas fait pour ça, les développeurs le disent eux même), ya toujours accès à tous les processus tournant sur l'hote, ya toujours un accès complet aux interfaces réseaux. etc. Ça ne fait qu'isoler du FS, mais ça ne sécurise rien du tout.
> 
> Sinon un minimum à faire, c'est de mettre cet environnement chroot sur une partition à part, ainsi ça n'aura aucun impact sur le reste si jamais la partition se remplit.

 

Oui, je sais je sais; mais je suis pas d'accord pour autant.

Je re-explique ... Pour dépanner des potes "facilement", j'ai prévu de créer un user qui possède un compte en ssh. Ce compte ne sert qu'a ouvrir un tunnel et donc, crer une socket. Après, je ne veux pas que l'utilisateur puisse : 

- voir les fichiers d'ailleur

- tenter de télécharger/composer un script ou autre

Ok, les "injections" ok, si tu veux. Mais soyons honête, avec la technique et un shell sécurisé (sans boucle et peut être sans ">") ; comment veut tu qu'une attaque soit réussie si elle ne vient pas de l'extérieur ? (attaque directe de sshd) ???

Car ... l'utilisateur pourra créer un fichier ... imaginons un copier/coller ... ok .. ben, il n'y a pas "sh"  et il n'y a pas de "chmod" ... le fichier ne sera pas en exécutable ... La seule faile que je constate actuelleement, c'est l'écriture de fichier "polution" qui boufferais l'espace disque. Pour le reste, j'ai vraiment du mal à imaginer puisque aucun outil n'est à disposition de l'utilisateur sur ce compte. Donc pour moi, la sécurité est suffisante mais je suis d'accord avec toi, il y aura tjs des failles (en attaquant le port sshd) ... maintenant, je ne vois absolument pas comment tu pourrais agir sur les processus :

```
-jail-3.2$ htop

-jail: htop: command not found

-jail-3.2$ top

-jail: top: command not found

-jail-3.2$ ps

-jail: ps: command not found

-jail-3.2$ dmesg

-jail: dmesg: command not found

-jail-3.2$ kill

kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]

-jail-3.2$ killall

-jail: killall: command not found
```

Ok, il y a bien "kill" ... Est-il possible de le supprimer ?    Et même si il est présent .. tu n'est qu'un petit user, tu ne vois même pas les pids vu que tu sais pas lister ... Maintenant, si tu sais comment lister les pids sans les commandes habituelles, je suis preneur....

----------

## loopx

 *truc wrote:*   

> Bah tu peux lui mettre rbash comme shell par exemple, tu vas voir, c'esst très très limité...

 

Heu  :Surprised: 

```
serveur loopx # emerge -s rbash

Searching...

[ Results for search key : rbash ]

[ Applications found : 1 ]

*  games-fps/ut2004-hamsterbash [ Masked ]

      Latest version available: 1

      Latest version installed: [ Not Installed ]

      Size of files: 96,296 kB

      Homepage:      http://www.eigensoft.com/hamsterbash.htm

      Description:   UT2004 Hamster Bash - Cute and violent hamster cage rampage mod

      License:       freedist
```

Tu le trouve ou ?

EDIT:

Ok c'est bon, je viens de capter  :Very Happy:    il est fourni avec bash ..

http://sohei.forumactif.com/pc-f27/rbash-ou-comment-limiter-les-utilisateurs-t40.htm

EDIT2: rbash à vraiment l'air bien et permettra d'éviter les problèmes de protection dont je parle plus haut  :Smile:        merci de l'info, je connaissais pas du tout  :Smile: 

----------

## geekounet

 *loopx wrote:*   

>  *geekounet wrote:*   Quelque soit le shell que tu mettes, la moindre faille permettant une injection permettra à l'utilisateur de faire ce qu'il veut. De plus, un chroot (parce que ce "jail" sous Linux n'est que ça, ça n'est pas le vrai jail des BSD qui lui est vraiment sécurisé) n'apporte aucune securité (ce n'est pas fait pour ça, les développeurs le disent eux même), ya toujours accès à tous les processus tournant sur l'hote, ya toujours un accès complet aux interfaces réseaux. etc. Ça ne fait qu'isoler du FS, mais ça ne sécurise rien du tout.
> 
> Sinon un minimum à faire, c'est de mettre cet environnement chroot sur une partition à part, ainsi ça n'aura aucun impact sur le reste si jamais la partition se remplit. 
> 
> Oui, je sais je sais; mais je suis pas d'accord pour autant.
> ...

 

Ne le prend pas mal mais je pense que t'ignores encore beaucoup de choses sur la sécurité, et que t'es loin de te douter de ce qui est possible de faire... une injection de code, je ne parle pas d'attaques extérieurs sur ton sshd ou autre, mais bien d'attaques locales depuis ce shell limité. Et il n'y a aucun besoin d'"outils en ligne de commande" pour faire cette attaque, une simple faille dans bash, du genre un buffer overflow tout bête (et bash en a déjà eu, et aura encore et toujours, c'est assez commun comme problème pour un shell), peut permettre d'injecter du code binaire (en ram hein, dans le processus qui tourne déjà), et à partir de là d'executer les syscalls qu'il veut (donc causer au kernel, voir les processus extérieurs et causer avec s'il le peut, causer à l'interface réseau et s'en servir pour envoyer du spam ou autre actes malfaisants, exploiter la première faille kernel connue pour passer root et ensuite sortir du chroot et faire tout ce qu'on veut, etc.). Que ton shell soit limité sur l'interaction utilisateur et qu'il n'y ai pas d'atures executables dans le chroot ça n'empêchera rien de tout ça, le pirate s;en fout, il n'en a pas besoin, juste de l'injection de code dans le bash qui tourne déjà en exploitant une de ses éventuelles failles, quelques syscall qui vont bien (c'est à dire les interactions bas niveau avec le kernel, que n'importe quel programme est capable de faire pour n'importe quelle opération basique, genre charger une lib, créer/coper/supprimer un fichier, etc.) et voilà.

Je pense que tu devrais étudier de plus près ces genres de choses, parce que t'as une vision trop simpliste de la sécurité, c'est bien plus subtil et complexe que ça. Et puis ça a l'air de t'intéresser comme sujet donc ça vaudrait le coup pour toi.

----------

## loopx

@geekounet :

Merci pour les infos, et non je le prend pas mal. Tu n'es pas le premier à me rappeler ce genre de chose. Je suis fort critique et tant qu'on ne me prouve pas exactement, j'ai du mal à y croire. Maintenant, ne t'inquiète pas, je sais ce qu'on peut faire avec un pc sur linux  :Wink:    pas de souci, je te crois. Mais il y a un truc que je comprendrais peut être jamais, c'est comment tu fais une injection (vu qeu c'est une des failles les plus connue avec un shell super restreint) ?

Est-ce du genre : copier/coller de machin pourri en gise de "commande devant être exécuté par bash" ? Avec des caractères magique and co ? Si oui, ok, je te suis ... mais si c'est pas ca, j'aurais vraiment du mal à voire comment ce serait possible vu que les commandes basique ne sont plus trop présente.

J'ai fait de l'informatique et je vois bien les injections du genre "sql injection", et je comprend très bien .. mais avec bash + injection, c'est vrai que j'ai encore du mal.

@truc: 

Je suis suuuuuuuper décu  :Sad:    je viens de tester "rbash" et franchement, les "restrictions" attendue ... ne sont tout bonnement pas présente!  :Sad: 

http://sohei.forumactif.com/pc-f27/rbash-ou-comment-limiter-les-utilisateurs-t40.htm :

 *Quote:*   

> Théorie
> 
> Bash (Bourne Again SHell) propose un mode "restreint". Il ne faut pas confondre restreint et sécurisé, mais ce mode peu permettre à un administrateur de limiter grandement les actions des utilisateurs. "rbash" ou "bash --restricted" s’utilise comme un bash normal, à l’exception des fonctionnalités suivantes qui ont été supprimées :
> 
>     * Changer de répertoire avec la commande "cd".
> ...

 

Dans la pratique :

```
Last login: Mon Apr 13 18:43:42 2009 from loop

-jail-3.2$ echo $SHELL

/bin/rbash

-jail-3.2$ echo /bin/*

/bin/rbash

-jail-3.2$ echo "test d'ecriture dans un fichier" > toto

-jail-3.2$ echo *

toto

-jail-3.2$ pwd

/home/support

-jail-3.2$ cd ..

-jail-3.2$ pwd

/home
```

Je n'irais pas plus loins dans les tests car le ">" et le "cd" sont déjà de trop  :Sad:           ou est la suppression de ">" ? Ou est la suppression de "cd" ?  :Sad: 

Je précise que j'ai supprimé l'environnement "/var/chroot" et que j'ai tout recréé en utilisant "rbash" car j'avais déjà mis bash et qu'il n'y a pas de script pour la suppression de software ... donc, j'ai tout refait en ajotuer rbash et non bash. Mais voilà, déception ultime ou mensonge ? L'effet attendu ... s'attendra encore ..

EDIT: je précise que j'ai utilisé ce howto pour jail :

http://www.gentoo-wiki.info/Jail#Start_by_emerging_it

----------

## kernelsensei

si tu veux simplement faire un tunneling, sans acces shell ni rien, tu peux tenter un truc de ce genre :

- Le user créé une clef ssh

- Pour le shell du user tu mets /bin/false

- dans le /home/le_user/.ssh/authorized_keys2 tu mets command="/bin/cat",no-pty avant la clef rsa, par exemple :

```
command="/bin/cat",no-pty ssh-rsa AAAAB3NzaC1yc2EAAA........................................
```

L'utilisateur pourra se logger avec ssh -N user@host -D<numero de port> pour tu dynamic forwarding par exemple. Tu peux rajouter l'option -f pour que ssh aille en tache de fond après..

----------

## truc

 *loopx wrote:*   

> @truc
> 
> ...

 

Euh, je ne sais pas trop quoi dire, chémouasamarche  :Razz: 

```
$ echo $SHELL

/bin/rbash

$ cd www/

-rbash: cd: restricted

$ echo "qsfdq" > tt

-rbash: tt: restricted: cannot redirect output

```

----------

## loopx

 *kernelsensei wrote:*   

> si tu veux simplement faire un tunneling, sans acces shell ni rien, tu peux tenter un truc de ce genre :
> 
> - Le user créé une clef ssh
> 
> - Pour le shell du user tu mets /bin/false
> ...

 

Ouf, kernelsensei, j'ai cru que tu venais pour me gronder   :Laughing: 

Le shell "/bin/false" pourraient être intéressant. Si je remplace le "rbash" par le "false" et que je me log normalement sur le serveur ... qu'est-ce qu'il se passe ?

Sinon, pour ta technique, j'essaie de te suivre ... Je n'ai pas besoin de clé (bah, suis pas un fan des clés en ssh) mais bon, si nécessaire, why not. Le shell, la je te suis plus ou moins : "false" ... je sais pas à quoi ca doit ressembler une fois loggé, mais ca doit être plus sécure que bash ^^. Alors, le 3ème point, je n'y comprend plus rien  :Very Happy:    ok pour la clé ... mais le paramètre "command", il sert à quoi ? A exécuter un cat infini, pour que la session ssh ne se termine jamais vu que c'est du "false" ??????

Après, pour la commande ssh pour la connexion, pas sur que tu ai compris ... 

```
N      Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only).
```

Cette option serait-elle à utiliser obligatoirement avec "false" ?

Sinon, je n'ai pas besoin d'un -D... En fait, c'est un client quelconque qui est "en panne" et qui est caché derrière moulte nat & firewall qui se connectera en utilisant un :

```
ssh -R 5000:localhost:22 user@serveur
```

Donc, il tirera son port localhost:22 sur mon serveur:5000 ... ainsi, je n'y plus qu'a me connecter moi-même en ssh pour remonter chez lui en traversant tout firewall/nat  :Smile: 

----------

## loopx

 *truc wrote:*   

>  *loopx wrote:*   @truc
> 
> ... 
> 
> Euh, je ne sais pas trop quoi dire, chémouasamarche 
> ...

 

 :Surprised: 

what's the fuck  :Surprised:  ?

EDIT: jjvais boude,r ca y est  :Sad: 

et ainsi, ca fonctionne chez toi ?

```
serveur chroot # rbash

serveur chroot # cd ..

rbash: cd: restricted
```

pfffffffffffffffffffffffffff  :Sad:  :Sad:  :Sad:    what's the fuck!?    :Shocked: 

EDIT: ce ne serait pas dans les variables d'env ou dans le .bash_profile qu'il y aurait un problème ?

```
-jail-3.2$ echo $

$BASH             $BASH_SUBSHELL    $EUID             $HOME             $LOGNAME          $OPTIND           $PS2              $SHELLOPTS        $UID

$BASH_ARGC        $BASH_VERSINFO    $GROUPS           $HOSTNAME         $MACHTYPE         $OSTYPE           $PS4              $SHLVL            $USER

$BASH_ARGV        $BASH_VERSION     $HISTCMD          $HOSTTYPE         $MAIL             $PATH             $PWD              $SSH_CLIENT       $_

$BASH_COMMAND     $COLUMNS          $HISTFILE         $IFS              $MAILCHECK        $PIPESTATUS       $RANDOM           $SSH_CONNECTION

$BASH_LINENO      $COMP_WORDBREAKS  $HISTFILESIZE     $LINENO           $OLDPWD           $PPID             $SECONDS          $SSH_TTY

$BASH_SOURCE      $DIRSTACK         $HISTSIZE         $LINES            $OPTERR           $PS1              $SHELL            $TERM
```

Je viens de virer tout les fichiers de l'utilisateur sous /home et /var/chroot/home ... Rien a faire, il restreint rien du tout .. pourtant, si je tape "rbash" ... il restreint bien, je comprend pas   :Shocked: 

EDIT2: 

```
serveur support # cat /etc/shells

# /etc/shells: valid login shells

/bin/bash

/bin/csh

/bin/esh

/bin/fish

/bin/ksh

/bin/sash

/bin/sh

/bin/tcsh

/bin/zsh

/usr/bin/jail

/usr/bin/jail

/usr/bin/jail

/usr/bin/jail
```

Ou est "rbash" ? Normal qu'il ne s'y trouve pas ?

EDIT3: 

```

serveur bin # pwd

/var/chroot/bin

serveur bin # ./rbash

serveur bin # cd ..

rbash: cd: restricted
```

c'est la fête aux cloches, je sais, .. mais quand même   :Mad: 

----------

## kernelsensei

la clef et le -N sont nécessaires ; avec /bin/false (ou /bin/true, peut importe) tu n'obtiens pas de shell.

Que tu utilises -D ou -R c'est pas un problème, ça fonctionnera pareil, je viens de tester.

Concernant command="/bin/cat", ça dit a ssh d'executer cat et rien d'autre. C'est vrai que normalement c'est utile quand tu n'utilises pas /bin/false, donc obsolète dans notre cas. Lancer cat sans argument permet de laisser la connexion ssh ouverte dans rendre la main, mais effectivement avec /bin/false et l'option -N c'est pluso ou moins pareil il me semble.

----------

## loopx

 *kernelsensei wrote:*   

> la clef et le -N sont nécessaires ; avec /bin/false (ou /bin/true, peut importe) tu n'obtiens pas de shell.
> 
> Que tu utilises -D ou -R c'est pas un problème, ça fonctionnera pareil, je viens de tester.

 

Ah oki, merci  :Smile: 

J'utilisais le -D uniquement pour créer un proxy sock 5 pour partager le net d'un pc  :Smile: 

EDIt: je viens de tomber la dessus :

http://www.scribd.com/doc/958626/Shells-restreints-haking9

bref, un document qui à l'air sympa, mais j'aimerais bien télécharger le PDF sans me loger... j'essaie avec le code source de trouver un lien mais je trouve pas; personne n'est assez malin que pour leur prendre ce doc ??   :Laughing: 

----------

## kernelsensei

Ya une discussion à ce propos ici : http://www.authsecu.com/nntp/fr-comp-securite/26945-fr-comp-securite-ssh-tunnel-sans-acces-shell.htm

----------

## truc

Tu peux regarder sur bugmenot, tu trouveras eut-être ton bonheur (si t'utilises firefox, y'a même une extension permettant d'aller fouiller pour toi sur le site bugmenot, et de remplir les formulaires tout seul, classe quoi..  :Wink:  )

----------

## loopx

 *truc wrote:*   

>  *loopx wrote:*   @truc
> 
> ... 
> 
> Euh, je ne sais pas trop quoi dire, chémouasamarche 
> ...

 

Tu pourrais me dire si c'est au login (/etc/passwd) que tu utilise rbash ou si c'est juste "comme ca" en tapant "rbash" ? Car je suis tombé sur un très vieux post, et visiblement, ca bug si tu place "rbash" dans /etc/passwd ... au login donc...

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=170298

----------

## truc

oui, c'est mon shell par défaut, quand je me logge, c'est ce que j'ai (c'est justement le pc d'un pote, qui me donne gracieusement un accès comme tu t'apprètesà le faire)

(celui défini dans /etc/passwd)

----------

## loopx

 *truc wrote:*   

> oui, c'est mon shell par défaut, quand je me logge, c'est ce que j'ai (c'est justement le pc d'un pote, qui me donne gracieusement un accès comme tu t'apprètesà le faire)
> 
> (celui défini dans /etc/passwd)

 

Avec ou sans chroot ? 

Pff, ca me fou les boules quand même  :Sad: 

----------

## truc

 *loopx wrote:*   

> Avec ou sans chroot ? 

 

sans

----------

## loopx

 *truc wrote:*   

>  *loopx wrote:*   Avec ou sans chroot ?  
> 
> sans

 

Ok, d'accord ... Je vais faire un test :

- création d'un new user avec home

- lui mettre un mot de passe

- ajouter le user a la config sshd pour l'autoriser

- tester la connexion ssh distante => OK

- editer /etc/passwd et passer "/bin/bash" en "/bin/rbash"

- tester la connexion ssh distante => KO

Donc, le fait de modifier /etc/passwd me tue le login .. impossible en rbash ...   :Shocked: 

```

(avec rbash)

Apr 13 20:52:34 serveur sshd[31791]: error: PAM: Authentication failure for test from loop

Apr 13 20:52:39 serveur sshd[31809]: error: PAM: Authentication failure for test from loop

Apr 13 20:53:14 serveur sshd[31809]: error: PAM: Authentication failure for test from loop

Apr 13 20:53:15 serveur sshd[31842]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=loop  user=test

(avec bash)

Apr 13 20:53:47 serveur sshd[31866]: Accepted keyboard-interactive/pam for test from 10.2.1.6 port 45762 ssh2

Apr 13 20:53:47 serveur sshd[31866]: pam_unix(sshd:session): session opened for user test by (uid=0)
```

mais c'est un truc de fou le rbash   :Shocked:      j'ai vraiment pas de bol today

EDIT: ok j'en teisn un !!!! 

```
Last login: Mon Apr 13 20:58:33 2009 from loop

test@serveur ~ $ echo $SHELL

/bin/rbash

test@serveur ~ $ cd ..

-rbash: cd: restricted
```

J'ai réussi .. si il ne voulais pas se loger, c'est parce que le shell "rbash" ne se trouvait pas dans "/etc/shells"

EDIT2: 

```
Last login: Mon Apr 13 20:59:58 2009 from loop

-jail-3.2$ echo $SHELL

/bin/rbash

-jail-3.2$ cd ..

-jail-3.2$

```

pourtant, impossible de se loger en "rbash" avec support .. car c'est du chrooted et que le shell utilisé au début (dans le non chrooted) est "jail" et non "rbash" ... une fois chrooté, il passe en "rbash". Je vais faire un test ...

EDIT3: le test était de copier le "/etc/shells" dans l'environnement chrooté ... rien n'y fait.  Puis alors, je me suis dit : tiens, qu'est ce que ca donne quand on est en "rbash" et qu'on exécute "rbash" .. la, c'est une bonne :

```
Last login: Mon Apr 13 21:04:43 2009 from loop

-jail-3.2$ cd ..

-jail-3.2$ rbash

rbash-3.2$ pwd

/home

rbash-3.2$ cd

rbash: cd: restricted

rbash-3.2$ cd ..

rbash: cd: restricted
```

donc, je vais devoir préciser à l'utilisateur de ce compte de faire un "rbash" une fois connecté pour être sur qu'il ne puisse pas faire un truc suspect .. ca risque fort d'être bidon   :Laughing: 

EDIT4: y aurait-il moyen de faire un "workaround" avec le profile bash ? Genre, forcer l'exécution ou autre de rbash une deuxixème fois ...?

EDIT5: pour ceux qui voudrait faire la même chose que moi pour m'aider (un tit test), voici ou j'en suis arrivé :

http://pix-mania.dyndns.org/mediawiki/index.php/Jail#Tutoriels

EDIT6: peut être une piste : un use manquant ? quelqu'un pourrait m'aider car je connais pas les uses de bash :

```
[ebuild     U ] app-shells/bash-3.2_p39 [3.2_p33] USE="nls -afs -bashlogger -examples% -plugins -vanilla" 2,582 kB
```

----------

## loopx

Ok, j'ai trouvé un "workaround"  :Smile: 

sur le serveur :

```
echo "exec rbash" > /var/chroot/etc/profile
```

le client :

```
Last login: Mon Apr 13 23:47:54 2009 from loop

rbash-3.2$ cd ..

rbash: cd: restricted

rbash-3.2$ exit

exit

Connection to serveur closed.

loopx@loop ~ $
```

avec le "exec", on écrase le rbash qui ne restreint rien du tout  :Wink: 

maintenant, si quelqu'un pouvait me dire si ce workaround ne pose pas de problème de sécurité ...   :Cool: 

----------

## loopx

Ouf, j'ai failli avoir peur  :Very Happy: 

```
loopx@loop ~ $ ssh support@serveur "echo echo > /etc/profile"

Password:

jail: /etc/profile: Permission denied
```

 :Cool: 

Mais si jamais le fichier de profile était accessible en écriture à l'utilisateur "support", il m'aurait cassé mon rbash   :Rolling Eyes: 

----------

## loopx

Bah en fait, j'ai fais ceci maintenant :

```
chmod a-w /var/chroot -R
```

Maintenant, personne n'écrira ou il ne faut pas ^^

----------

## loopx

 *kernelsensei wrote:*   

> si tu veux simplement faire un tunneling, sans acces shell ni rien, tu peux tenter un truc de ce genre :
> 
> - Le user créé une clef ssh
> 
> - Pour le shell du user tu mets /bin/false
> ...

 

Hello,

Je remonte ce poste car la solution citée ci-dessus m'intéresse grandement pour mon boulot. Je dois faire en sorte qu'un utilisateur puissent exécuter des commandes root sur divers serveurs. Une solution serait d'utiliser des clé + SUDO pour donner l'accès à certaine commande. Le filtre sur les commandes (dans la clé SSH) m'intéresse grandement et de plus, j'aimerais pouvoir éviter qu'un utilisateur ai un shell à sa disposition (si il vole la clé par exemple).

Donc, est-il possible d'utiliser la solution ci-dessus pour l'exécution de commande SSH sans avoir de shell pour autant ? Je limiterais les commandes via la clé SSH (ainsi que d'autre .. genre tunnel, etc .. si vous avez une liste, ca m'aiderais). SUDO sera à un autre niveau permettant de filtrer les paramètres et donner les droits de root pour certaine commande.

----------

## loopx

Bon, je viens de tester la clé RSA + paramètre "command" et "no-pty" ... Je constate que si je place le "no-pty", ma commande n'est plus exécutée  :Sad:   et ca me demande le pass. Y aurait-il un conflit entre ces deux paramètres ?

EDIT: en fait, "no-pty" n'est pas nécessaire dans le cas d'une commande de validation déjà activée .. En effet, tout passe par le script .. Donc, si j'exécute un ssh normal pour avoir un shell, c'est la commande qui sera exécutée, donc mon script, et une fois terminé, il quittera et donc, aucun shell donné à l'utilisateur  :Wink: 

no-pty est donc inutile .. enfin, je pense ..

----------

