TL; DR
A única maneira de impedir que um usuário crie aliases é fornecer a eles um shell que não suporte o alias. Este é geralmente um problema X / Y, onde X é realmente um modelo de ameaça que deve ser resolvido com controles ou arquiteturas apropriados ao invés de tentar resolver o problema post-facto depois que um usuário recebe um shell um sistema compartilhado.
Abaixo, eu forneço uma resposta tecnicamente correta, bem como algumas orientações sobre quais problemas isso irá resolver ou não. Eu também forneço algumas orientações adicionais sobre controles alternativos.
Usando o shell restrito ao Bash
Você pode usar o shell restrito do Bash, atribuindo o rbash como shell de login do usuário. Por exemplo:
foo:x:2001:2001:restricted user:/home/foo:/bin/rbash
Você deve então desabilitar o alias embutido para o usuário, de preferência sem quebrar o shell de todos os demais. Como exemplo, você pode adicionar o seguinte a um arquivo como /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
Advertências
A menos que você tenha colocado o usuário em uma cadeia chroot ou tenha fornecido um PATH
modificado que não inclua acesso a outros shells, não há nada que impeça o usuário de simplesmente digitar
bash em o prompt e obtendo um shell irrestrito.
Além disso, por design, o shell restrito impede muitas atividades comuns, como a alteração de diretórios:
$ cd /tmp
rbash: cd: restricted
mas não impede que outros scripts ou programas no PATH façam isso. Isto significa que você tem que criar cuidadosamente o ambiente do usuário, e especificamente que você precisa impedir que eles modifiquem o PATH em seus arquivos de inicialização, porque mesmo que o rbash faça PATH somente leitura, ele faz isso após inicialização.
Melhores escolhas
Mesmo se você usar o rbash, será necessário fazer isso como parte de um conjunto mais amplo de controles. Alguns exemplos podem incluir:
-
Evite que usuários não técnicos ataquem acidentalmente comandos perigosos, fornecendo aliases padrão como rm -i , mv -i e cp -i no /etc/bash.bashrc arquivo.
- Dado o seu exemplo original, esta é provavelmente a solução mais sensata.
- Você pode combinar isso com
enable -n alias , se quiser.
- Isso não impedirá que os usuários qualificados alterem os aliases, mas isso pode ser suficiente para impedir que usuários não técnicos façam o que você está preocupado.
-
Permissões Unix tradicionais ou POSL ACLs para proteger arquivos e diretórios.
-
Logins que executam um único comando não interativo. Por exemplo:
foo:x:2001:2001:run foo.sh:/home/foo:/usr/local/bin/foo.sh
-
Use comandos forçados SSH por chave. Por exemplo:
# ~foo/.ssh/authorized_keys
command="/usr/local/bin/foo.sh" [remainder of line]
-
Use o OpenSSH ForceCommand com um bloco de correspondência condicional.
-
Use ferramentas especiais como gitolite ou scponly projetado para seu caso de uso específico.
-
Use uma cadeia chroot .
-
Use a virtualização, como o Xen, o OpenVZ, o LXC, o VMware, o VirtualBox ou outras tecnologias para fornecer um ambiente separado.
Depois de definir com precisão o seu modelo de ameaça, você pode identificar os controles mais apropriados para o seu caso de uso. Sem um entendimento mais significativo de por que você quer evitar o aliasing (por exemplo, qual problema do mundo real ele resolve?), Você não pode selecionar os controles mais apropriados.