Por que os servidores da web são iniciados tradicionalmente como superusuário?

Question

Pensando em uma futura configuração de servidor da web, percebi que, por algum motivo, os servidores da web geralmente começam como root e, em seguida, descartar certos direitos ( setuid ) para os processos de trabalho. Além disso, muitas vezes há chroot envolvido, o que não significa exatamente como uma medida de segurança.

O que eu estava me perguntando, por que os servidores da Web (eu tenho administrado tudo, do Apache, lighttpd ao nginx) não usam o sistema de recursos ( capabilities(7) ), como CAP_NET_BIND_SERVICE , no Linux e simplesmente iniciar como usuário não root? ... desse jeito ainda escutando em uma porta privilegiada abaixo de 1024.

Ou melhor, acho que a maioria deles poderia, mas por que essa prática não é comum? Por que não ...

• use setcap(8) com CAP_NET_BIND_SERVICE no binário sendo executado?
• configure as pastas de log para permitir que o usuário (não raiz) escreva lá
• ..., se você sentiu que chroot ajuda, use chroot ou lxc para "prender" o servidor web?

Não há nada que não seja (filho) processo filho pode matar pai que eu poderia inventar que tornaria isso menos benéfico do que começar imediatamente como root .

Então, por que eles estão sendo iniciados tradicionalmente como root quando depois tudo é feito para se livrar dos problemas de segurança implícitos que vêm com ele?

    

Answer 1

Embora o POSIX possua um padrão para recursos que, acredito, inclua CAP_NET_BIND_SERVICE, eles não são necessários para conformidade e pode de certa forma ser incompatível com a implementação, por exemplo, no linux.

Como os servidores web como o apache não são escritos para apenas uma plataforma, o uso de privilégios de root é o método mais portátil. Eu suponho que isso poderia ser feito especificamente no Linux e no BSD (ou onde quer que o suporte seja detectado), mas isso significaria que o comportamento variaria de plataforma para plataforma, etc.

Parece-me que você poderia configurar seu sistema para que qualquer servidor web pudesse ser usado dessa maneira; há algumas sugestões (talvez desajeitadas) sobre esse apache do WRT aqui: NonRootPortBinding .

So why are they traditionally being started as root when afterwards everything is done to get rid of implied security issues that come with it?

Eles são iniciados como root porque geralmente precisam acessar uma porta privilegiada, e tradicionalmente essa é a única maneira de fazer isso. A razão pela qual eles fazem o downgrade depois é porque não precisam de privilégios posteriormente e para limitar o potencial de dano introduzido pela miríade de software complementar de terceiros comumente usado pelo servidor.

Isso não é irracional, já que a atividade privilegiada é muito limitada e, por convenção, muitos outros daemons do sistema executam raiz continuamente, incluindo outros daemons inet (por exemplo, sshd ).

Lembre-se de que se o servidor fosse empacotado para que pudesse ser executado como um usuário não privilegiado com CAP_NET_BIND_SERVICE, isso permitiria que qualquer usuário não privilegiado iniciasse o serviço HTTP (S), que é talvez um risco maior.

    

Answer 2

Em sistemas baseados em Unix, os serviços que atendem em portas privilegiadas requerem a bênção do administrador do sistema. Isso indica que o serviço está sendo executado por um usuário confiável (pelo menos pelo administrador). Os usuários de tais serviços podem, então, confiar que haja alguma supervisão administrativa do aplicativo do servidor. O valor dessa confiança pode não ser tão grande quanto nas décadas anteriores.

Muitos servidores da web são executados em kernels de sistema operacional mais antigos que podem não suportar os recursos necessários para permitir que ele seja iniciado e executado como um usuário não privilegiado. As mudanças necessárias no kernel são relativamente novas e não são padronizadas nos kernels do sistema operacional. É possível compilar condicionalmente o software para esses ambientes. No entanto, essas alterações não podem ser usadas na maioria das plataformas e podem não ser bem testadas ou tão seguras quanto desejado.

É comum que os processos do daemon sejam executados como root para fazer tudo o que requer acesso root e, em seguida, alternar para um UID sem privilégios. Isso permite que os recursos sejam protegidos, evitando que o programa cause muito dano quando estiver em execução. No caso de um servidor web, as chaves SSL devem ser protegidas contra leitura por um aplicativo do servidor rouge, mas devem ser lidas para configurar o listener SSL. O privilégio de divisão permite o acesso com recursos divididos a recursos que podem ser usados para aumentar significativamente a segurança.

Embora seja possível prender um servidor da Web, em muitos sistemas, a cadeia pode conter partes significativas do sistema de arquivos. Isso pode ser difícil de configurar e propenso a erros. Presa de uma aplicação geralmente implica que é uma configuração mais segura. Nesse caso, essa confiança pode ser perdida devido ao risco de que a cadeia esteja incorretamente configurada. Mesmo sem uma cadeia, pode ser difícil diagnosticar problemas de acesso. Ter grandes partes do sistema de arquivos excluídas da cadeia tornaria isso mais difícil.

    

Answer 3

Existem vários motivos para iniciar um servidor da Web como root:

• para ligar à porta 80 (as portas abaixo de 1024 são reservadas para raiz, de modo que, se um usuário remoto estiver se conectando a um serviço em uma porta baixa, elas sabem que esse serviço é aprovado pelo root);
• para configurar o confinamento, por ex. chroot;
• para ler e exibir as páginas da web dos usuários, onde aplicável.

Essa menor razão é uma configuração ruim; A maneira mais simples de proteger essa configuração é exigir que os usuários tornem as páginas da Web públicas. Isso não funciona quando os usuários podem querer ter páginas da Web privadas com controle de acesso (por exemplo, uma máquina universitária em que os professores desejam compartilhar textos de exames pela Web, mas não querem permitir que os alunos os visualizem). Nesse caso, é necessária uma abordagem mais sofisticada (por exemplo, exigir que as páginas da Web tenham uma ACL que permita que o servidor da Web as leia).

Os servidores da Web que são iniciados como root geralmente só iniciam como root, mas depois descartam privilégios para um usuário dedicado. Antes de eliminar privilégios, eles ligam a porta 80, possivelmente leem alguns arquivos (por exemplo, arquivo de chave privada SSL) e possivelmente executam outra contenção.

[Why not] use setcap(8) with CAP_NET_BIND_SERVICE on the binary being run?

Isso pode ser feito, mas requer um sistema que suporte recursos. Em relação ao histórico do Unix e até mesmo aos servidores da Web, isso é relativamente recente.

[Why not] set up the log folders to allow the (non-root) user to write there?

Isso geralmente é feito; ou então o processo do servidor web registra através de um soquete Unix ou Internet em um daemon de registro.

[Why not] if you felt like chroot helps at all, use chroot or lxc to "jail" the web server?

Isso significa que o servidor web poderá ler todos os seus arquivos de configuração, como chaves privadas SSL. Às vezes, as vulnerabilidades permitem que atacantes remotos recuperem arquivos arbitrários; confinar o servidor de forma a impedir que ele acesse arquivos de configuração evita a exposição nesse caso.

É uma fraqueza da maioria dos sistemas unix que eles não permitem que um processo sem privilégios configure uma área de confinamento da qual ele não será capaz de se livrar. No Linux, isso é possível desde as melhorias no namespace do kernel 3.8 , que ainda não estão amplamente disponíveis.