Como impedir que os usuários executem comandos via barra oblíqua para um diretório?

Question

Alguém sabe se é possível restringir a execução de comandos via notação de barra para um diretório?

O ambiente é bash no Linux.

Por exemplo, eu tenho um diretório /usr/local/app/bin . Em /usr/local/app/bin é um comando chamado foo. Para alguns usuários, estou criando um alias durante o login para o foo que redireciona o foo para outro lugar.

Não quero que esses usuários possam executar o foo diretamente, copiando para /usr/local/app/bin e executando:

$ ./foo

Esses usuários precisam ser capazes de executar outros comandos em / usr / local / app / bin, mas não importa se eles estão impedidos de executar esses outros comandos via ./ .

No final, meu objetivo é impedir que determinados usuários executem foo interativamente ao fazer logon interativamente. Por exemplo (aproximadamente), em .bashrc:

if [ -z "$PS1" ]; then
:
else
alias foo="echo access denied!"
fi

Isso funciona, exceto que os usuários podem executar o foo diretamente usando ./ de / usr / local / app / bin O arquivo precisa ser executável, mas somente quando o caminho completo é usado. Espero que alguém conheça uma maneira inteligente de realizar isso

    

Answer 1

Tudo é possível dependendo de quão profundo você deseja ir. Supondo que você não queira invadir seu shell, kernel ou entrar no selinux ou no AppArmour. Não, você não pode impedir que as pessoas executem o foo (via ./foo ou de outra forma) sem alterar as permissões do sistema de arquivos ou acls.

No Linux, um executável é feito executável com base nas permissões de arquivo e posix acls. Se eles podem executá-lo, então eles podem executá-lo, apenas o próprio executável pode verificar se ele deve ser executado com o caminho completo. Se for apenas um problema de caminho simples, você poderia envolvê-lo em um shell e verificar o argumento $ 0, mas, para segurança, isso é apenas uma ofuscação e qualquer um com uma dica conseguirá arredondar em segundos.

Caso contrário, isso é tratado através de acls e executabilidade de usuário e grupo. No entanto, você precisa gerenciar as contas de usuário e os grupos e arquivos do sistema de arquivos.

Normalmente, os arquivos são de propriedade da conta de administrador, portanto, para a maioria das contas de usuário, eles executam as tarefas por meio do grupo ou de outra permissão.

Remova a permissão de execução de "outro".

chmod o-x /path/to/foo

Mova a participação no grupo de foo para um grupo confiável e verifique se a permissão de execução do grupo está definida.

chgrp trusted /path/to/foo
chmod g+x /path/to/foo

Agora você tem que colocar todos os usuários que devem ser capazes de executar foo no grupo confiável.

for eachUser in a potentially a big long list of user accounts
do
    usermod --append --groups trusted $eachUser
done

E a sobrecarga de gerenciamento disso é porque as permissões tradicionais do Unix são péssimas.

Para posix acls você pode simplesmente adicionar o usuário ao arquivo, mas sem a permissão de execução. Use getfacl para ler a lista de controle de acesso.

for eachUser in a smaller list of restricted users
do
    setfacl -m user:$eachUser:000 /path/to/foo
done

Como a entrada acl está lá para a conta do usuário, ela tem precedência sobre as permissões padrão do usuário / grupo / outro sistema de arquivos e o usuário não tem permissão para o arquivo. Todos os outros poderão usar o arquivo normalmente.

Melhor matematicamente, é colocar todas as contas restritas em um grupo e adicionar o grupo ao arquivo sem permissões em vez de usuários individuais.