Version imprimable
Bonjour,
Je suis sur un serveur sous Centos 6.4 que j'ai intégré à un domaine Windows. Tout marche comme il faut. Les utilisateurs peuvent se connecter sur le serveur Linux avec leurs propre compte AD. Sauf que l'idée pour moi et d'interdire au utilisateur du domaine AD d'utiliser un autre shell que bash. Est-il possible?
Merci d'avance
Bonjour,
Oui, c'est possible, tu les mets dans une cage (chroot) et tu leur interdit de pouvoir créer des fichiers exécutables sur les partitions où ils ont accès en écriture.
Bon courage :aie:
Salut
Te suffit de virer tous les /bin/*sh en ne gardant que /bin/sh et /bin/bash...
Maintenant, avis personnel, je n'en vois pas l'utilité. Question sécurité cela n'apporte rien et peut-être que certains users aimeraient bosser en /bin/csh ou autre...
Arf t'as mal lu. Il ne veut pas interdire à ses utilisateurs de créer des shells, il veut juste les forcer à n'utiliser que /bin/bash.Citation:
Envoyé par disedorgue
Toutefois ta remarque me permet de rebondir sur l'option "noexec" de mount qu'on peut répercuter dans /etc/fstab. Très pratique dans le cas que tu cites...
Bah oui, sinon, rien n'empêche ces utilisateurs de télécharger un autre shell pour l'utiliser.
Comme pas de détails, je vais à l'extrême :aie:
Peut-être que si tu nous dis pourquoi tu veux cela, on comprendra mieux ton besoin... et on aura plus de billes pour te répondre...Citation:
Envoyé par mouadsa
Qu'adviendra-t-il aux utilisateurs d'un domaine différent du domaine AD???Citation:
Envoyé par Sve@r
J'ai un peu peur pour eux... 8O
Il y a un truc qui s'appelle "Les permissions".
Pourquoi ne pas mettre tous ceux qui n'appartiennent pas à AD dans un groupe antiAD qui aurait accès aux *sh ?
Notez le x du groupe et le - du reste du monde.Code:
2
Je pense ausi que la solution avec les droits est la plus simple mais je trouve qu'avec des acl, ce serait plus simple
Bien vu. Toutefois t'as laissé le droit "r". Rien n'interdit donc de copier ce ksh chez-soi et donner le droit x à la copie...Citation:
Envoyé par Flodelarab
Bonjour,
Les solutions proposees sont interessantes, mais le plus interessant serait de savoir pourquoi limiter l'utilisation a bash !
On est d'accord, car rien n'empêche de récupérer un shell autre que bash dans son home et de l'utiliser... et je ne parle pas du renommage de fichier...
Sinon, il ne faut pas aussi oublié les commandes tel que chsh et compagnie qui peuvent permettre de changer sont shell de démarrage...
Tu peux interdire l'exécution dans /home en passant l'option dans /etc/fstab, tu peux aussi interdire la lecture ( et donc la copie ) des autres shellCitation:
Envoyé par disedorgue
Je suis d'accord avec ça, mais les utilisateurs, ils doivent faire quoi sur la machine ?
Car si leur boulot c'est de créer des fichiers exécutables, je ne vois pas comment autoriser et interdire en même temps le droit d’exécution.
Pour l'interdiction des autres shell, je suppose que les utilisateurs se connecte en ssh, donc rien n'empêche de rapatrier un shell via le réseau.
Donc, comme je le disais plus haut, on manque cruellement d'informations sur la finalité du besoin :cry:
Il est bien connu qu'interdire 'sh' et autoriser 'bash' garantit la sécurité des serveurs! MDRCitation:
Alors pour t'expliquer un petit peu les choses, ça vient principalement de l'idée que sh permet de faire pleins de conneries, ce qui impacte la sécurité des serveurs utilisés en mode production. Voilà en bref l'intérêt d'interdire sh.
Quel est le besoin? :roll:
Si on n'a pas confiance dans son client, faut pas le laisser exécuter qqch sur le serveur.
Les serveurs PHP l'ont bien compris. Il ne laisse pas les clients internet exécuté le moindre code ("personnel") par les internautes.