Quão útil é montar / tmp noexec?

38

Muitas pessoas (incluindo o Securing Debian Manual ) recomende a montagem /tmp com o conjunto de opções noexec,nodev,nosuid . Isso geralmente é apresentado como um elemento de uma estratégia de 'defesa em profundidade', impedindo a escalada de um ataque que permite que alguém grave um arquivo ou um ataque de um usuário com uma conta legítima, mas sem outro espaço gravável.

Com o tempo, no entanto, eu encontrei argumentos (mais proeminentemente pelo Desenvolvedor Debian / Ubuntu Colin Watson) que noexec é uma medida inútil, por algumas razões em potencial:

  1. O usuário pode executar /lib/ld-linux.so <binary> em uma tentativa de obter o mesmo efeito.
  2. O usuário ainda pode executar intérpretes fornecidos pelo sistema em scripts que não podem ser executados diretamente

Considerando esses argumentos, a necessidade potencial de mais configuração (por exemplo, debconf gosta de um diretório temporário executável) e a possível perda de conveniência, essa é uma medida de segurança que vale a pena? Que outros buracos você conhece que permitem a evasão?

    
por Phil Miller 08.10.2009 / 01:43

6 respostas

29

Aqui estão os argumentos para o utilitário que eu criei até agora:

Os kernels modernos consertam o buraco /lib/ld-linux.so , para que ele não possa mapear as páginas executáveis de um sistema de arquivos noexec .

O ponto dos intérpretes certamente ainda é uma preocupação, embora eu ache que menos do que as pessoas podem reivindicar. O raciocínio que posso apresentar é que houve inúmeras vulnerabilidades de escalonamento de privilégios que dependiam da criação de syscalls malformadas. Sem um atacante fornecendo um binário, seria muito mais difícil fazer syscalls malignos. Além disso, os intérpretes de script devem ser desprivilegiados (eu sei que isso, historicamente, às vezes não tem sido o caso, como com um suid perl), e assim precisaria de sua própria vulnerabilidade para ser útil em um ataque. Aparentemente, é possível usar o Python, pelo menos, para executar alguns exploits.

Muitas explorações "enlatadas" podem tentar escrever e executar executáveis em /tmp e, portanto, noexec reduz a probabilidade de cair em um ataque por script (digamos, na janela entre divulgação de vulnerabilidades e instalação de correções).

Assim, ainda há um benefício de segurança para a montagem de /tmp com noexec .

Como descrito no rastreador de bugs do Debian , definindo APT::ExtractTemplates::TempDir em apt.conf para um diretório que não é noexec e acessível para root iria evitar a preocupação do debconf.

    
por 08.10.2009 / 01:46
7

Muitos pacotes Debian exigem que o / tmp seja executável para que o pacote seja instalado. Estes são frequentemente marcados como erros (da gravidade 'normal' / 'lista de desejos'):

link

Eu recebi apenas este erro enquanto instalava um kernel atualizado para o ramo estável ainda hoje.

Então parece que o Debian (& derivados?) não está pronto para o / tmp ser montado no no ...

    
por 21.08.2010 / 04:07
6

adicione o seguinte ao /etc/apt.conf, ou, /etc/apt/apt.conf.d/50remount

DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};
    
por 30.08.2010 / 04:37
4

Embora existam soluções alternativas para a maioria das medidas de segurança suplementares que você pode implementar, mesmo as medidas de segurança mais facilmente evitadas (como montagem / tmp noexec ou execução de SSH em uma porta alternativa) impedirão ataques automatizados ou com script que dependem do padrões para funcionar. Ele não protege você contra um invasor determinado e experiente, mas, em mais de 99% do tempo, você não enfrentará um invasor determinado ou experiente. Em vez disso, você estará se defendendo contra um script de ataque automatizado.

    
por 21.08.2010 / 05:17
2

Primeiro: Abrange muitos casos de ataques diferentes Desligá-lo porque havia algumas maneiras conhecidas (algumas até fixas) é estranho. Atacantes fazendo o download de código para / dev / shm ou / tmp é uma coisa comum que eles fazem.

Defesa em profundidade é sobre como proteger os waypoints mais comuns, cada um que os impede de tornar seu sistema mais viável. Não é seguro. Mas também terá uma chance . Se eles não podem buscar sua carga útil secundária, essa é uma boa chance que você está tendo.

  • Também pode ser parado por restrições de usuário do iptables.
  • Também pode ser parado pelo SELinux.
  • Também pode ser não interrompido devido a uma outra exploração facilmente acessada.

O objetivo é facilitar tanto quanto você e cortar 99% dos ataques.

Segundo: Ele pára a má prática (executando coisas de temp, fazendo grandes instalações de aplicativos via / tmp ao invés de um usuário tmpdir), deixando dados em / tmp. Instaladores personalizados geralmente entendem o TMPDIR Além disso: mesmo se não: o tempo de instalação, como uma ação point-in-time, não é um motivo válido para desativar um problema de segurança permanentemente .

Terceiro: Considerando namespaces anônimos em / tmp (um "recurso"), você realmente quer restringir o que está lá e executar a partir daí.

Anterior: Conveniência não é um fator relevante nisso. Assumindo que geramos servidores por dinheiro e com um propósito: somos responsáveis por essas coisas. "Ah, eu não tranquei / tmp porque preciso de mais alguns minutos para atualizar meu software no próximo ano". Certamente não será apenas uma coisa que fica entre ser chantageado e estar bem. Um ótimo motivo? Eu não penso assim.

Que tal este:

"We learned that enemies can attack without notice. They could also use hundreds of spies to poison the food. So we stopped handing out guns to our soldiers."

Espere, o que?

Há outras medidas que exigem muito mais esforço, experiência e sorte para garantir um sistema e saber que as pessoas têm dinheiro limitado, expectativa de vida e também gostariam de passar tempo com suas famílias: Não pule as coisas fáceis .

    
por 21.11.2016 / 11:44
1

Existem aplicativos que exigem que o / tmp seja executável para instalação. Em um trabalho anterior, antes de eu chegar lá, os administradores tinham configurado / tmp noexec, mas descobri que o pacote db2 não seria instalado. Mesmo se você descompactar o pacote db2 em algum outro lugar, o procedimento de instalação copia alguns arquivos para / tmp e espera poder executá-lo, o que obviamente falhou com a permissão negada. Se você não está ciente de que o sistema de arquivos está montado noexec, pode ser um pouco enganador. Só foi possível continuar a instalação depois de remontar / tmp sem noexec.

De qualquer forma, o ponto é que pelo menos um produto comercial requer que / tmp não seja montado noexec, e pode haver outros. Eu não encontrei uma razão realmente convincente para isso. Se você quer uma segurança melhor, eu prefiro o selinux.

    
por 25.08.2015 / 15:13