Como jail um servidor fastcgi (ou um servidor web-proxied)?

6

Se você tiver um servidor da Web (por exemplo, nginx), muitas vezes você usa um servidor fast-cgi ou outro servidor de aplicativos http para obter conteúdo dinâmico. Isso significa que em ambos os casos você tem uma boa separação de processos entre o processo web-server e o fast-cgi (ou processo application-http-server - no escravo chamado a seguir).

O servidor web é configurado de forma que o cgi rápido passa por um soquete ou o pedido http é intermediado por proxy.

Criando usuários diferentes para o escravo e o servidor web, você pode proteger a localização do sistema de arquivos, se houver um problema de segurança no processo escravo.

Mas como faço para prender o processo escravo ainda mais no Linux?

(Tal que não pode acessar a rede, enviar e-mails, etc.)

Posso pensar nas seguintes rotas:

  • SELinux
  • namespaces do sistema Linux ('containers', cgroups )

Qual é a maneira mais conveniente em uma distribuição atual como, por exemplo, Debian? Como fazer isso na prática? Algum exemplo de configuração?

    
por maxschlepzig 09.06.2011 / 16:08

3 respostas

1

No Ubuntu, outra forma de prisão é apparmor !

É um módulo de segurança Linux (LSM) de controle de acesso obrigatório baseado em caminho (MAC). No Ubuntu 10.04, ele é ativado por padrão para serviços selecionados.

A documentação é bastante fragmentada. A documentação do Ubuntu pode ser ... melhor. Mesmo a documentação a montante não apresenta uma boa introdução. Os estados da página de referência :

WARNING: this document is in a very early stage of creation it is not in any shape yet to be used as a reference manual

No entanto, começar é relativamente fácil. Um perfil do AppAmor corresponde a um caminho do executável, por ex. %código%. A regra padrão de um perfil é negar (o que é ótimo), se nada mais corresponder. As regras de negação de perfil correspondem sempre antes de regras de permissão. Um perfil vazio nega tudo.

Perfis para binários diferentes são armazenados em /var/www/slave/slave . /etc/apparmor.d exibe quais perfis estão ativos, quais estão no modo enforce (bom) ou somente no modo de reclamação (somente mensagens de log são impressas).

Criar um novo perfil para apparmor_status é apenas:

aa-genprof /var/www/slave/slave

Inicie em outro terminal /var/www/slave/slave e faça um caso de uso típico. Depois que terminar, pressione /var/www/slave/slave e s no terminal anterior.

Agora, f contém um arquivo de perfil /etc/apparmor.d . Se o escravo faz alguma bifurcação, o perfil é apenas muito esparso - todos os acessos das crianças são ignorados.

De qualquer forma, o perfil agora está ativo no modo de imposição e você pode apenas acionar iterativamente as ações no escravo e assistir var.www.slave.slave às violações. Em outro terminal, você edita o arquivo de perfil e executa tail -f /var/log/messages após cada alteração. O log exibe então:

audit(1308348253.465:3586):  operation="profile_replace" pid=25186 name="/var/www/slave/slave"

Uma violação se parece com:

operation="open" pid=24583 parent=24061 profile="/var/www/slave/slave" 
  requested_mask="::r" denied_mask="::r" fsuid=10004 ouid=10000 name="/var/www/slave/config"

Uma regra de perfil como:

/var/www/slave/config r,

permitiria o acesso no futuro.

Tudo isso é muito simples.

O AppAmor é compatível com regras de rede com granularidade grossa, por exemplo

network inet stream,

Sem essa regra, não é possível acessar a Internet (incluindo o host local), ou seja, com essa regra, você pode usar aa-enforce var.www.slave.slave para regras mais refinadas (por exemplo, com base no uid do escravo).

Outro fragmento de documentação contém algo sobre os sub-perfis para scripts php.

O esqueleto do perfil do var.www.slave.slave se parece com:

#include <tunables/global>

/var/www/gapapp/gap.wt {

  #include <abstractions/base>

  network inet stream,

  /var/www/slave/config r,
  /var/www/slave/exehelper/foo ix,
  /var/www/slave/db/* rw,

  ...
}

Com esse perfil, o escravo não pode mais chamar utilitários como iptables ou mail .

    
por 18.06.2011 / 01:16
1

Existe outra maneira de prendê-lo: iptables usando a extensão de correspondência do proprietário!

Com o iptables, é possível bloquear o tráfego de rede de saída (OUTPUT) por todos os processos do usuário escravo. Isso é muito fácil de configurar, ou seja, é conveniente.

Isso significa que, com essa configuração fácil, você pode prender seu processo escravo das localizações do sistema de arquivos e da rede.

$ iptables -N slave_chain
$ iptables -A slave_chain -m owner --uid-owner 10004 -p tcp --dport 1:1024 -j REJECT
$ iptables -A slave_chain -m owner --uid-owner 10004 -p tcp -d 127.0.0.1 -j ACCEPT
$ iptables -A slave_chain -m owner --uid-owner 10004 -j REJECT
$ iptables -A OUTPUT -j slave_chain

Onde 10004 é o uid do usuário escravo. O escravo precisa apenas responder às solicitações do servidor da Web em proxy. Tudo o resto é rejeitado, por ex. uma tentativa de conexão ao MTA na porta localhost 25 para enviar SPAM.

Note que o escravo pode enviar e-mail através de comandos como mail ou sendmail , se estiverem disponíveis, ou seja, é necessário mais detenção de localizações fs (por exemplo, chroot / cgroups) ou é preciso configurar o MTA para permitir o envio de mensagens pelo usuário escravo.

    
por 17.06.2011 / 18:32
0

Os cgroups são uma forma de prisão. Desde 2007, os subsistemas cgroups contêm os chamados namespaces de rede .

As distribuições atuais incluem ferramentas do userspace para contêineres do Linux , uma coleção de ferramentas de linha de comando ( lxc-* ) e exemplos de arquivos de configuração. Eles também incluem um exemplo de namespace de rede.

Infelizmente, o Ubuntu 10.04 (LTS) rompe namespaces de rede com uma atualização recente do kernel .

Em suma, a documentação sobre o lxc não é tão detalhada, você tem que vasculhar alguns arquivos de configuração de exemplo.

Não está claro qual é a melhor prática para configurar contêineres sem raiz.

    
por 18.06.2011 / 00:27

Tags