Explicação de nodev e nosuid no fstab


44

Vejo essas duas opções constantemente sugeridas na Web quando alguém descreve como montar um tmpfs ou ramfs. Muitas vezes também com noexec, mas estou especificamente interessado em nodev e nosuid. Eu basicamente odeio repetir cegamente o que alguém sugeriu, sem entender de verdade. E como só vejo instruções de copiar / colar na rede sobre isso, pergunto aqui.

Isto é da documentação:
nodev - Não interpreta dispositivos especiais de bloco no sistema de arquivos.
nosuid - Bloqueia a operação de bits suid e sgid.

Mas eu gostaria de uma explicação prática do que poderia acontecer se eu deixasse esses dois de fora. Digamos que eu configurei tmpfs ou ramfs (sem essas duas opções mencionadas definidas) que sejam acessíveis (leitura + gravação) por um usuário específico (não raiz) no sistema. O que esse usuário pode fazer para prejudicar o sistema? Excluindo o caso de consumir toda a memória do sistema disponível no caso de ramfs


1

Respostas:


36

Você não precisa seguir isso cegamente como uma regra difícil. Mas o raciocínio para situações mais focadas na segurança é o seguinte.

  • A opção de montagem nodev especifica que o sistema de arquivos não pode conter dispositivos especiais: Esta é uma precaução de segurança. Você não deseja que um sistema de arquivos acessível ao usuário como este tenha o potencial de criar dispositivos de caracteres ou acessar hardware de dispositivo aleatório.

  • A opção nosuid mount especifica que o sistema de arquivos não pode conter arquivos de ID do usuário definidos. Impedir binários setuid em um sistema de arquivos gravável em todo o mundo faz sentido, porque há um risco de escalonamento da raiz ou outras horrendas por lá.

Pelo que vale, eu não uso esses parâmetros frequentemente ... apenas em sistemas públicos, onde existem outras considerações de conformidade.


1
Na verdade, eu tenho um sistema público, porque o software está sendo executado sob essa conta que é exposta à rede. Então, eu estou me perguntando sobre cenários hipotéticos aqui. E se alguém obtiver acesso ao shell através de alguma vulnerabilidade. Claro que há outras coisas que ele poderia fazer para aumentar os direitos, mas eu gostaria de minimizá-los. Então, eu estou pensando, por exemplo, em suid, o usuário ainda não seria capaz de alterar esse sinalizador, independentemente de o sistema de arquivos permitir ou não. A opção nosuid está impedindo apenas software acidentalmente mal configurado (por uma raiz)? Ou um usuário pode explorá-lo sozinho?
Ivan Kovacevic

1
@IvanKovacevic Você não precisa usar as opções recomendadas de montagem do sistema de arquivos. Eles estão lá para reduzir o vetor de ataque. Examinar cenários hipotéticos pode estar além do escopo desta questão.
ewwhite

3
@whwhite: sobre nosuido bit setuid não é ignorado? (em vez de The nosuid mount option specifies that the filesystem cannot contain set userid files)
user2284570
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.