Empêcher toutes les commandes d'être définies comme un alias

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

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

Il n'y a 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 le permettent où ils le souhaitent.
2. Vous supprimez toutes les mentions d'alias dans /etc/bash.bashrc, et tous ~/.bashrcet ~/.bash_aliasesvia un script. Ils ont mis leurs alias dans un autre fichier et l'ont source.
3. Vous exécutez une commande PROMPT_COMMANDqui désactive certains alias. Ils redéfinissent ou définissent PROMPT_COMMAND.
4. Vous piègez DEBUGet indéfinissez les alias. Ils retirent le piège.
5. Vous affichez tous les fichiers provenant de l'invocation à la racine. Ils utilisent un autre fichier et le source manuellement comme première commande qu'ils exécutent.
6. Vous désactivez les fonctions intégrées unset, builtinet enable; faire aliasune fonction ; declare -rf aliaspour empêcher les utilisateurs de modifier la fonction; et exporter la fonction. Ils s'exécutent /bin/bashavec --rcfileet --init-filepour démarrer un nouveau shell, où lesdits builtins sont maintenant activés.
7. ...

Vous pouvez désactiver les alias au moment de la compilation, alors ce serait à vous de garder bash à jour et de vous assurer que vous n'êtes pas affecté par le prochain Shellshock. Bien sûr, les utilisateurs pouvaient créer leur propre bash.

TL; DR

La seule façon d'empêcher un utilisateur de créer des alias est de lui fournir un shell qui ne prend pas en charge l'alias. Il s'agit généralement d'un problème X / Y, où X est vraiment un modèle de menace qui devrait être résolu avec des contrôles ou des architectures appropriés plutôt que d'essayer de résoudre le problème a posteriori après qu'un utilisateur ait reçu un shell sur un système partagé.

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

Utilisation du shell restreint Bash

Vous pouvez utiliser le shell restreint de Bash en affectant rbash comme shell de connexion de l'utilisateur. Par exemple:

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

Vous devez ensuite désactiver l' alias intégré pour l'utilisateur, de préférence sans casser le shell de tout le monde aussi. Par exemple, vous pouvez ajouter ce qui suit à 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

Avertissements

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

De plus, de par sa conception, 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 d'autres scripts ou programmes du PATH de le faire. Cela signifie que vous devez soigneusement créer l'environnement de l'utilisateur, et en particulier que vous devez l'empêcher de pouvoir modifier le PATH dans ses fichiers de démarrage, car même si rbash rend PATH en lecture seule, il le fait après l' initialisation.

De meilleurs choix

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

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

  • Compte tenu de votre exemple d'origine, c'est probablement la solution la plus judicieuse.
  • Vous pouvez combiner cela avec enable -n aliassi vous le souhaitez.
  • Cela n'empêchera pas les utilisateurs avertis de modifier les alias, mais cela peut être suffisant pour empêcher les utilisateurs non techniques de faire tout ce qui vous préoccupe.

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

• 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 les 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 la gitolite ou scponly conçus pour votre cas d'utilisation spécifique.

• Utilisez une 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 des raisons pour lesquelles vous voulez empêcher l'alias (par exemple, quel problème réel résout-il?), Vous ne pouvez pas sélectionner les contrôles les plus appropriés.

C'est une entreprise tout à fait inutile, comme le montre la réponse de muru. Mais il y a quelques options, mais elles ne sont pas parfaites.

Selon le bashmanuel, les fonctions ont toujours la priorité sur les alias, donc nous pourrions faire ce qui 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 l'ensemble du système .bashrc, mais comme l'a souligné muru, les utilisateurs intelligents trouveront un moyen d'obtenir des alias en achetant un bashrcfichier différent par exemple.

Une autre idée avec laquelle j'ai joué est enableintégrée. aliasest un shell intégré, et basha une belle enablecommande qui permet d'activer ou de désactiver les commandes intégrées. Par exemple, voici moi 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 à l'échelle du système bashrcest une option ici.

Vous pouvez définir (dans /etc/profile) une fonction appelée aliasqui effectue la validation que vous souhaitez (probablement en utilisant type -p) (après que toutes les "commandes par défaut d'Ubuntu" sont des "exécutables $PATH") avant d'appeler la fonction intégrée alias, MAIS, comme d'autres l'ont souligné, vos utilisateurs pourraient obtenir autour de ça. Pourquoi ne pas obtenir un ensemble différent d'utilisateurs ou les éduquer ("Définir un aliasqui remplace une commande est un très bon moyen de se tirer une balle dans le pied, et de créer de la confusion (par exemple, pourquoi lsinvite-t-on mon mot de passe?))?