Por que o nginx inicia o processo como root?

Question

Eu instalei o servidor nginx. Acabei de verificar as portas de escuta e vi o seguinte:

$ sudo lsof -nP -i | grep LISTEN
sshd       614     root    3u  IPv4   7712      0t0  TCP *:22 (LISTEN)
nginx      822     root    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      827 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      828 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      829 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
nginx      830 www-data    7u  IPv4   8745      0t0  TCP *:80 (LISTEN)
.
.
.

Estou interessado apenas em saber por que existem quatro processos nginx executados como usuário 'www-data' e um como 'usuário root'?

    

Answer 1

O processo que você notou é o processo mestre, o processo que inicia todos os outros processos nginx. Este processo é iniciado pelo script de inicialização que inicia o nginx. A razão pela qual este processo está sendo executado como root é simplesmente porque você o iniciou como root! Você pode iniciá-lo como outro usuário, mas terá que garantir que todos os recursos necessários para o nginx estejam disponíveis para esse usuário. Isso seria tipicamente pelo menos / var / log / nginx e o arquivo pid sob / var / run /.

Mais importante ainda; Somente processos raiz podem escutar portas abaixo de 1024. Um servidor da Web normalmente é executado na porta 80 e / ou 443. Isso significa que ele precisa ser iniciado como root.

Em conclusão, o processo mestre sendo executado pelo root é completamente normal e, na maioria dos casos, necessário para a operação normal.

Editar: Executar qualquer coisa como root carrega um risco de segurança implícito. Normalmente os desenvolvedores deste tipo de software têm muito conhecimento sobre vetores de ataque e tomam muito cuidado para executar o mínimo possível como root. No final, você simplesmente tem que confiar que o software é de boa qualidade.

Se você ainda se sentir desconfortável, há uma maneira de executar nginx como outro usuário e ainda usar portas abaixo de 1024. Você pode usar iptables para redirecionar todo o tráfego de entrada na porta 80 para outra porta, por exemplo 8080, e ter nginx listen on essa porta.

    

Answer 2

A maioria dos servidores (Apache, Nginx, etc.) tem um processo pai de propriedade do root que, em seguida, cria cópias de nós de trabalho usando um usuário menos credenciado. Nesse caso, é www-data .

Exemplo

Se você der uma olhada no arquivo de configuração nginx , /etc/nginx/nginx.conf , você notará linhas como esta:

user nginx;
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;

A maioria dos servidores tem opções similares a esta que estipulam que usuário executar os nós escravos como e quantos deles.

Segurança

A exposição de serviços com acesso root é frequentemente mencionada como uma insegurança potencial. No entanto, você geralmente precisa ser o root para se ligar a portas que variam de 1-1024, então não há realmente nada que você possa fazer se quiser que um servidor esteja escutando, digamos, as portas 80 ou 443.

Além disso, se um serviço for bem escrito e configurado adequadamente, ele não é necessariamente prejudicial à sua postura de segurança. Os aplicativos executados no Apache & Nginx são realmente as verdadeiras fontes de estouro de buffer ou ataques de injeção de servidor SQL, já que os aplicativos são os serviços que estão expondo os pontos de entrada de dados malformados a serem injetados em sua pilha de servidores.

Apache & Nginx por si só, geralmente não aceitam nenhuma entrada além dos métodos GET / POST que aceitam.

    

Answer 3

É o modo como o aplicativo é empacotado. Na maioria dos * nix, a configuração padrão é um usuário não privilegiado que não pode escutar em uma porta < 1024 e servidores da web usam 80 e 443.

O Linux 2.2+, o Solaris 10+ e o FreeBSD permitem que usuários não-root escutem em portas menores que 1024, mas não por padrão. A maioria aceitou o uso de root para que permaneça em uso.

Diferente do acesso para vincular-se à porta privilegiada necessária para garantir que o usuário que está executando o nginx tenha acesso a todos os arquivos necessários. Você provavelmente não precisa ir tão longe quanto isso mas apenas defina a permissão correta em arquivos / diretórios. Você também precisa verificar se os scripts de inicialização não fazem nada dissimulado como ulimit changes (como o mysql sempre parece).

Recursos do Linux

setcap e getcap permite alterar ou exibir o recurso cap_net_bind_service de um executável. Isso estará em vigor para qualquer um que execute o binário.

setcap cap_net_bind_service=+ep /usr/sbin/nginx

O SELinux oferece a capacidade de configurar e controlar recursos em um nível de usuário.

Configurações do sistema Freebsd

As configurações da porta reservada são globais para o sistema

sysctl net.inet.ip.portrange.reservedhigh=0
sysctl net.inet.ip.portrange.reservedlow=0

Privilégios do Solaris

O Solaris fornece um controle refinado dos privilégios no nível do usuário. Esses são os privilégios para o apache, mas é provável que eles também trabalhem para o nginx.

/usr/sbin/usermod -K defaultpriv=basic,proc_exec,proc_fork,net_privaddr nginx

    

Answer 4

Gostaria de acrescentar mais respostas a todos. Embora o nginx seja iniciado como root, ele não está sendo executado como root. O usuário (nginx, www-data, etc) que está realmente executando como é geralmente um login restrito / preso (você não pode entrar com ele, apenas certos arquivos podem ser acessados). Este é um dos prós de usar o Linux para servidores web em oposição ao Windows. Esse processo é chamado de fork ( você pode encontrar mais detalhes neste artigo da Wikipédia ) e também usa setuid e / ou setgid ( que também é explicado em um artigo da Wikipedia ) para alterar o usuário e / ou grupo. Em uma configuração segura, um hacker não conseguirá acessar o processo pai e utilizar a conta raiz. Isso nem sempre é verdade, pois um hacker poderia utilizar algum tipo de exploração para obter acesso root (havia uma vulnerabilidade no nginx 1.4.0 e abaixo que permitia aos hackers obter acesso root).