web-dev-qa-db-fra.com

Empêcher que toutes les commandes soient définies comme un alias

Existe-t-il un moyen d'empêcher que toutes les commandes soient définies comme un alias?

Par exemple, un utilisateur ne devrait pas pouvoir définir rm ni aucune autre commande (commandes par défaut Ubuntu) sous un nom d'alias.

bashalias
10
αғsнιη

Il n’ya aucun moyen d’empêcher un utilisateur de définir les alias qu’il préfère. Considérer:

  1. Vous désactivez les alias dans /etc/bash.bashrc. Ils l'activent partout où ils le souhaitent.
  2. Vous supprimez toutes les mentions d'alias dans /etc/bash.bashrc, ainsi que tous les ~/.bashrc et ~/.bash_aliases via un script. Ils mettent leurs alias dans un autre fichier et le recherchent.
  3. Vous exécutez une commande dans Prompt_COMMAND qui désactive certains alias. Ils redéfinissent ou définissent Prompt_COMMAND.
  4. Vous piègez DEBUG et indéfinissez des alias. Ils enlèvent le piège.
  5. Vous avez chown tous les fichiers provenant de l’invocation à la racine. Ils utilisent un autre fichier et le source manuellement en tant que première commande exécutée.
  6. Vous désactivez les fonctions intégrées unset, builtin et enable; faire alias une fonction ; declare -rf alias pour empêcher les utilisateurs de modifier la fonction; et exporter la fonction. Ils exécutent /bin/bash avec --rcfile et --init-file pour démarrer un nouveau shell, où les fonctions intégrées sont maintenant activées.
  7. ...

Vous pouvez désactiver les alias au moment de la compilation, puis vous devez vous tenir au courant et vous assurer que vous n'êtes pas concerné par le prochain Shellshock. Bien sûr, les utilisateurs peuvent créer leur propre bash.

24
muru

TL; DR

Le seul moyen d'empêcher un utilisateur de créer des alias consiste à lui fournir un shell ne prenant pas en charge les alias. Il s’agit généralement d’un problème X/Y, où X est un modèle de menace qui doit être résolu avec des contrôles ou des architectures appropriés plutôt que de tenter de résoudre le problème post-facto après un utilisateur. reçoit un shell sur un système partagé.

Ci-dessous, je donne une réponse techniquement correcte, ainsi que des indications sur les problèmes que cela va résoudre et ne va pas résoudre. Je fournis également quelques conseils supplémentaires sur les contrôles alternatifs.

Utilisation du shell restreint Bash

Vous pouvez utiliser le shell restreint de Bash en assignant rbash en tant que shell de connexion de l'utilisateur. Par exemple:

foo:x:2001:2001:restricted user:/home/foo:/bin/rbash

Vous devez ensuite désactiver le alias intégré pour l'utilisateur, de préférence sans endommager le shell de tous les autres. Par exemple, vous pouvez ajouter ce qui suit dans un fichier tel que /etc/profile.d/rbash.sh :

# Limit effect to users in a specific UID range.
if ((UID >= 2000)) && ((UID < 3000)); then
    # Check Shell options; disable alias builtins when Shell is restricted.
    if [[ $- =~ r ]]; then
        enable -n alias
        enable -n unalias
    fi
fi

Mises en garde

Sauf si vous avez placé l'utilisateur dans une prison chroot ou lui avez fourni un CHEMIN modifié qui n'inclut pas l'accès à d'autres shells, rien n'empêche l'utilisateur de taper simplement bash à l'invite et obtenir un shell illimité.

De plus, par définition, le shell restreint empêche de nombreuses activités courantes telles que la modification de répertoires:

$ cd /tmp
rbash: cd: restricted

mais n'empêche pas les autres scripts ou programmes du CHEMIN de le faire. Cela signifie que vous devez créer avec soin l'environnement de l'utilisateur, et plus particulièrement pour l'empêcher de modifier CHEMIN dans ses fichiers de démarrage, car même si rbash rend CHEMIN en lecture seule c'est le cas après initialisation.

Meilleurs choix

Même si vous utilisez rbash, vous devez le faire dans le cadre d'un ensemble plus large de contrôles. Quelques exemples peuvent inclure:

  • Empêcher les utilisateurs non techniques de accidentellement d'appeler des commandes dangereuses en fournissant des alias par défaut tels que rm -i, mv -i et cp -i dans le /etc/bash.bashrc fichier.

    • Compte tenu de votre exemple initial, c'est probablement la solution la plus judicieuse.
    • Vous pouvez combiner ceci avec enable -n alias si vous le souhaitez.
    • Cela n'empêchera pas les utilisateurs avertis de changer les alias, mais cela suffira peut-être à empêcher les utilisateurs non techniques de faire ce que vous craignez.

  • Autorisations Unix traditionnelles ou ACL POSIX pour protéger les fichiers et les répertoires.

  • Les connexions qui exécutent une seule commande non interactive. Par exemple:

    foo:x:2001:2001:run foo.sh:/home/foo:/usr/local/bin/foo.sh

  • Utilisez des commandes forcées SSH par clé. Par exemple:

    # ~foo/.ssh/authorized_keys
command="/usr/local/bin/foo.sh" [remainder of line]

  • Utilisez l'option OpenSSH ForceCommand avec un bloc de correspondance conditionnel.

  • Utilisez des outils spéciaux tels que gitolite ou scponly conçus pour votre cas d'utilisation spécifique.

  • Utilisez un prison chroot .

  • Utilisez la virtualisation telle que Xen, OpenVZ, LXC, VMware, VirtualBox ou d’autres technologies pour fournir un environnement séparé.

Une fois que vous avez défini avec précision votre modèle de menace, vous pouvez identifier les contrôles les plus appropriés pour votre cas d'utilisation. Sans une compréhension plus significative de pourquoi , vous souhaitez empêcher la création d'alias (par exemple, quel problème réel faut-il résoudre?), Vous ne pouvez pas sélectionner les contrôles les plus appropriés.

10
CodeGnome

Comme le montre la réponse de Muru, il s’agit là d’un effort plutôt inutile. Mais il y a quelques options, mais elles ne sont pas parfaites.

Selon le manuel bash, les fonctions ont toujours la priorité sur les alias. Nous pourrions donc procéder comme suit:

xieerqi@eagle:~$ function alias { echo "Aliases are no-no" ; }
xieerqi@eagle:~$ alias TEST='rm'
Aliases are no-no

Vous pouvez placer la définition de fonction dans le .bashrc global du système. Toutefois, comme l'a souligné Muru, les utilisateurs intelligents trouveront un moyen d'obtenir des alias en créant un fichier bashrc différent, par exemple.

Une autre idée avec laquelle j'ai joué est enable intégrée. alias est un shell intégré et bash possède une commande Nice enable qui permet d'activer ou de désactiver les fonctions intégrées. Par exemple, je suis en train de désactiver alias.

xieerqi@eagle:~$ enable -n alias
xieerqi@eagle:~$ alias
No command 'alias' found, did you mean:
 Command '0alias' from package 'zeroinstall-injector' (universe)
alias: command not found
xieerqi@eagle:~$ alias TEST='rm'
No command 'alias' found, did you mean:
 Command '0alias' from package 'zeroinstall-injector' (universe)
alias: command not found
xieerqi@eagle:~$ enable alias
xieerqi@eagle:~$ alias
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='ls --color=auto'
xieerqi@eagle:~$

Encore une fois, l’utilisation de _ dans tout le système bashrc est une option ici.

5
Sergiy Kolodyazhnyy

Vous pouvez définir (dans /etc/profile) une fonction appelée alias qui effectue la validation souhaitée (probablement avec type -p) (après que toutes les "commandes par défaut Ubuntu" sont "exécutables dans $PATH") avant d'appeler le module intégré alias, MAIS, comme d'autres l'ont souligné, vos utilisateurs pourraient contourner ce problème. Pourquoi ne pas obtenir un ensemble différent d’utilisateurs, ou les éduquer ("Définir un alias qui remplace une commande est un très bon moyen de se tirer dans le pied et de semer la confusion (par exemple, Pourquoi ls Demander mon mot de passe?))?

0
waltinator