Comment restreindre le shell des utilisateurs permettant d'exécuter des programmes shell

Est-il possible d'empêcher tout utilisateur de ne pas utiliser des commandes comme ls, rm et d'autres commandes système qui pourraient endommager le système. Mais les utilisateurs devraient pouvoir exécuter des programmes shell.

Votre question devrait être:

Je ne fais pas confiance à mes utilisateurs. Les idiots voient quelque chose sur Internet et l'essaient sans comprendre ce qu'il fait. Les sournois aiment fouiner et regarder les fichiers des autres et voler leurs idées. Et les paresseux, ne me lancez pas sur les paresseux.

Comment protéger mon système et mes utilisateurs de mes utilisateurs?

Tout d'abord, unix dispose d'un système d'autorisations de système de fichiers très complet. Cela semble être un tutoriel décent sur les autorisations du système de fichiers Unix . L'essentiel de ceci est que les répertoires peuvent être définis de telle sorte qu'un utilisateur peut aller dans un répertoire et peut exécuter des programmes à partir de ce répertoire mais ne peut pas afficher le contenu de ce répertoire. Si vous faites cela, par exemple, sur / home, si l'utilisateur exécute ls sur / home, il obtient une erreur d'autorisation refusée.

Si vous avez vraiment peur de vos utilisateurs et que vous souhaitez les coller dans un environnement restreint de type supermax , utilisez quelque chose comme les prisons de freebsd ou les zones de solaris - chaque utilisateur a son propre environnement sur mesure. Pour ajouter des points, utilisez ZFS afin de pouvoir prendre un instantané de l'environnement lorsqu'ils se connectent, donc s'ils suppriment leurs fichiers, vous pouvez simplement les retirer de l'instantané.

Il y a trois choses qui doivent être en place pour faire pleinement ce que vous demandez:

1. Un shell personnalisé qui n'a pas les commandes qui vous intéressent . C'est difficile à obtenir, mais si vous ne voulez vraiment pas que les utilisateurs aient accès à certaines primitives shell, c'est le seul moyen de les supprimer.
2. Définissez correctement les autorisations de fichier . Vous ne voulez pas que les utilisateurs endommagent le système? Définissez les autorisations afin qu'ils ne puissent pas endommager le système même s'ils disposent des bons outils. De ces trois étapes, c'est l'étape la plus simple.
3. Utilisez une technologie de contrôle d'accès obligatoire comme AppArmor . Les MAC comme AppArmor et SELinux intègrent des autorisations dans le noyau. Ceux-ci empêchent les utilisateurs d'exécuter les bons outils même s'ils les trouvent quelque part (et comme les autorisations de fichier, les empêchent de les utiliser en dehors de la zone restreinte).

Ceinture, bretelles et une agrafeuse pour faire bonne mesure. Difficile de se tromper là-bas.

AppArmor est intéressant car le MAC d'un exécutable spécifique est hérité par tous ses enfants. Définissez la connexion d'un utilisateur comme étant /bin/bash-bob, définissez le profil AppArmor pour ce droit binaire spécifique, et la seule façon de sortir de cette prison d'autorisation est par le biais d'exploits du noyau. Si un script d'installation paresseux laissable en écriture /var/opt/vendor/tmpglobale pour une raison stupide, l'utilisateur utilisant /bin/bash-bobcomme shell ne pourra pas y écrire . Définissez le profil bash-bob pour autoriser uniquement l'écriture dans leur répertoire personnel et /tmp, et de telles erreurs d'autorisation ne peuvent pas être exploitées. Même s'ils trouvent en quelque sorte le mot de passe root, le profil AppArmor pour /bin/bash-bobs'appliquera toujours même après leur mise à sujour depuis suet le bashprocessus qu'il engendre sont des enfants /bin/bash-bob.

La partie difficile est de créer ce profil AppArmor.

1. Créez un profil AppArmor pour / bin / bash-bob et réglez-le en mode audit
2. Définissez le shell de connexion de Bob sur / bin / bash-bob
3. Connectez-vous en tant que Bob. Faites tout ce que vous voulez que Bob puisse faire.
4. Utilisez le journal d'audit pour créer le profil AppArmor (SUSE a des outils pour cela, pas sûr des autres distributions Linux). C'est monstrueusement fastidieux, mais doit se produire si vous avez besoin de ce niveau de sécurité.
   1. Vous ferez des choses comme:
      • Approbation de l'accès en lecture à la plupart des bibliothèques système
      • Approbation des droits de lecture et d'exécution sur les quelques commandes système autorisées sélectionnées
      • Approuver l'accès en écriture aux espaces temporaires
      • Approuver la création de socket, si nécessaire
5. Définissez la stratégie à appliquer.
6. Connectez-vous en tant que Bob, faites des choses.
7. Faites des ajustements.

À mon avis, vous n'avez besoin que des étapes 2 et 3, car en combinaison, elles empêchent toutes deux la possibilité de faire quoi que ce soit de nuisible en dehors de la boîte soigneusement construite que vous avez configurée dans ces deux étapes.

Eh bien, vous pouvez définir le shell de l'utilisateur sur un programme que vous avez écrit qui ne lui permet d'exécuter que certains scripts shell.

Bien sûr, cela ne serait aussi sûr que le programme et les scripts shell; dans la pratique, ce type de shell restreint n'est généralement pas sécurisé contre un attaquant intelligent.

N'essayez pas de limiter les commandes, limitez les autorisations sur les fichiers. Vous ne pouvez pratiquement pas limiter l'accès des gens aux appels système, donc tout ce que quelqu'un doit faire est de fournir sa propre copie des commandes "dangereuses" que vous ne voulez pas qu'il exécute, et vous êtes bourré.

Si vous souhaitez que l'utilisateur ne puisse exécuter que certains scripts / binaires, vous pouvez utiliser un shell restreint . Cela (comme le mentionne l'article Wikipedia) n'est pas complètement sécurisé, mais si vous pouvez garantir qu'aucune application autorisée à s'exécuter ne peut exécuter un nouveau shell, c'est une bonne alternative.

Pour configurer un shell restreint d'utilisateurs, définissez /bin/rbash(ou similaire, la plupart des shells passent en mode restreint lorsque le binaire est nommé r *** name *) en tant que shell d'utilisateurs. Ensuite, éditez **. Bashrc (ou équivalent) et définissez-le $PATHdans un répertoire où tous les binaires / scripts autorisés sont stockés.

Oui, c'est possible, mais en pratique, cela prendrait beaucoup de travail et de planification. Vous pouvez créer des scripts et les exécuter en tant qu'utilisation privilégiée, puis supprimer tous les privilèges de l'utilisateur en question. Ou, vous pouvez définir le shell de l'utilisateur sur quelque chose de votre propre fabrication qui ne lui permet de faire que ce que vous autorisez explicitement.

Cependant, les autorisations standard sous Linux rendent pratiquement impossible pour un utilisateur normal de "nuire au système". Quel genre de mal essayez-vous de prévenir? Il est trivial d'empêcher les utilisateurs d'installer des logiciels ou d'exécuter des programmes en dehors de leur répertoire personnel, et vous pouvez utiliser chroot pour verrouiller encore plus le système.

Vous voudrez peut-être essayer [lshell] [1] (shell limité).

lshell est un shell codé en Python, qui vous permet de restreindre l'environnement d'un utilisateur à des ensembles limités de commandes, de choisir d'activer / désactiver n'importe quelle commande via SSH (par exemple SCP, SFTP, rsync, etc.), de consigner les commandes de l'utilisateur, d'implémenter une restriction temporelle, et plus.

[1]: http://lshell.ghantoos.org/Overview lshell

La façon dont j'implémente habituellement ce type de restrictions nécessite que plusieurs conditions soient remplies, sinon la restriction peut être facilement contournée:

• L'utilisateur n'appartient pas au wheelgroupe, le seul autorisé à utiliser su(appliqué via PAM).

• L'utilisateur reçoit un fichier correctement sécurisé rbash avec une lecture seule PATHpointant vers un privé ~/bin, ce ~/bin/répertoire contient des liens vers des utilitaires simples:

  $ ll ~/bin
  total 0
  lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
  lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
  lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
  lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
  lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
  lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
  

• l'utilisateur reçoit un environnement restreint, en lecture seule (penser à des choses comme LESSSECURE, TMOUT, HISTFILEvariables).

• l'utilisateur est mappé à l'utilisateur SELinux staff_uet a le droit d'exécuter des commandes en tant qu'autre utilisateur comme requis via sudo.

• l'utilisateur /home, /tmpet /var/tmpsont éventuellement polyinstanciés via /etc/security/namespace.conf:

  /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
  /var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
  $HOME      $HOME/$USER.inst/              tmpdir:create   root
  

  En outre, /etc/security/namespace.initrend tous les fichiers squelettiques en lecture seule pour l'utilisateur et appartient à root.

De cette façon, vous pouvez choisir d' $USERexécuter n'importe quelle commande en son propre nom (via un lien dans le ~/binrépertoire privé , fourni via /etc/skel, comme expliqué ci-dessus), au nom d'un autre utilisateur (via sudo) ou aucun.

Oui, modifiez simplement les autorisations sur ces commandes.

Vous pourriez avoir une meilleure chance de combat en écrivant une commande shell qui se comporte selon vos besoins.

Qu'est-ce qui ne convient pas aux autorisations par défaut pour les utilisateurs normaux sous Linux?