Como eu posso ver, não há permissão de gravação para agrupar & outros, Então eles não podem criar qualquer arquivo / diretório aqui.
você só precisa ter certeza de que, se remover a permissão de gravação do root, o que acontecerá?
Há um host com um serviço local que recebe dados de um local remoto (por exemplo, http) e os salva localmente em /var/log/data/ em alguns mydir.
$ ls -al /var/log/data
drwxr-sr-x+ 4 root datalog 4096 Feb 4 18:59 .
drwxr-xr-x 4 root root 4096 Feb 4 18:59 ..
drwxr-sr-x+ 2 root service 4096 Feb 4 19:07 mydir
O serviço local é executado com serviço: propriedade do serviço.
Vamos supor que eu queira impedir a execução de um programa de exploração que
ser encontrado em /var/log/data/mydir :
-rwxr-sr-x 1 root service 133156 Jul 19 2014 exploit
Observe o bit "s" (setgid) no arquivo de exploração, o que o torna executado com direitos de grupo de serviço (o mesmo que o serviço local).
Como posso evitar que potenciais explorações sejam executadas lá?
Removendo "x" (go-x) de /var/log/data/ e /var/log/data/mydir ? Provavelmente iria atrapalhar o trabalho do serviço ...
Alguma outra ideia?
Como eu posso ver, não há permissão de gravação para agrupar & outros, Então eles não podem criar qualquer arquivo / diretório aqui.
você só precisa ter certeza de que, se remover a permissão de gravação do root, o que acontecerá?
Você pode usar uma ACL para impedir que todos os usuários gravem e executem permissões e, em seguida, permitir explicitamente que apenas o usuário da conta de serviço tenha o rwx completo. link
Você pode reduzir o risco de uma exploração persistente certificando-se de que o serviço não seja capaz de criar um arquivo executável em lugar algum. Para isso, verifique se todos os sistemas de arquivos que o serviço pode acessar atendem a pelo menos uma das seguintes condições:
noexec A execução do serviço em uma cadeia chroot ajudará a reduzir a parte do sistema de arquivos que o serviço pode ver . Você pode usar as montagens de bind para fazer uma vista de uma parte do sistema de arquivos em um local diferente.
Note que o setgid é principalmente um arenque vermelho aqui. Se o invasor puder criar um arquivo executável e puder enganar seu serviço para executá-lo, a exploração será executada com o grupo do serviço de qualquer maneira. Setgid é apenas um problema se o atacante puder criar um arquivo executável, setgid através de seu serviço e pode enganar outro usuário para executar o arquivo.
Observe também que você só recebe uma pequena quantidade de proteção dessa maneira. Se o invasor puder enganar seu sistema para executar o arquivo que ele carregou, é provável que ele já tenha uma maneira de executar código arbitrário. Uma coisa que você pode ganhar é que, se o invasor for impedido de gravar um arquivo executável, a exploração poderá não sobreviver a uma reinicialização do serviço. Contudo, isto assume que o vector de exploração é, e. alguma vulnerabilidade de rede e não, e. uma vulnerabilidade na análise de arquivos.
Uma abordagem alternativa para confinar seu serviço é usar uma estrutura de segurança como o SELinux . Escrever uma política pode ser um trabalho árduo, mas você tem mais controle.
Tags permissions security files linux