Como criar usuários presos?

5

Meus servidores executam o CentOS: Nginx + PHP-FPM (PHP via Fast-CGI). Cada site está em seu próprio VirtualHost.

Atualmente, o Nginx e o PHP-FPM são executados no root. Eu sei que isso é uma má prática, e não há razão para qualquer um dos sites ter acesso a arquivos fora de seu próprio diretório.

Como eu poderia criar usuários presos e instruir nginx & & php-fpm para tocar de acordo?

    
por Miko 05.12.2009 / 03:25

2 respostas

12

Ok, você está usando uma configuração estranha, mas em geral:

Primeiro, o linux não suporta jails true (estilo bsd) (a menos que você instale o openvz ou o vserver), mas configurar tudo para ser executado como um usuário não privilegiado + chroots pode melhorar seriamente a segurança. Executar as coisas como um usuário não-root é essencial, os chroots são apenas um obstáculo (indiscutivelmente considerável) para possíveis atacantes.

De acordo com o site php-fpm, o chrooting é suportado através de um comando de configuração. É claro que o php-fpm não tem nenhuma documentação ... Se você examinar o tarball de origem, poderá encontrar alguma documentação, ou pelo menos um exemplo de configuração. O link diz que a configuração do usuário, do grupo e do chroot é possível. Eu nunca usei o php-fpm, mas deve ser razoavelmente bom senso.

Para obter o nginx em execução como um usuário não-root, abra o arquivo de configuração nginx, localize a linha que começa com "user" e altere-a para um usuário não privilegiado no sistema. Crie um novo usuário com o nologin como shell ou use o usuário nobody.

Em seguida, o processo para fazer chroot em qualquer daemon é basicamente o seguinte:

  • Create a directory for the specific daemon's root
  • Create a skeleton directory structure in the chroot directory (so ./etc, ./usr/lib, etc)
  • Copy over any needed binaries and configuration files (so the nginx.conf, the nginx binary, any helper programs that you'll need)
  • Copy over additional files that are needed inside the chroot. This will be at least a stub of /etc/password file (not the shadow password file, there simply needs to be a way of looking up usernames to uids), /etc/group file, and /etc/localtime (php will complain endlessly if you don't have timezone info).
  • Lastly, run ldd on the binaries that you've copied over. This will give you a list of libraries to copy. Go through this list, and copy the needed shared objects to their equivalent place in the chrooted directory. Try to preserve symlinks, or copy the original file in the place where there was previously a symlink.
  • Create any needed devices with mknod. If you don't know the device numbers, google them (ex: /dev/random is c 1 8, /dev/null is c 2 2)
  • While the paths to things in your config files should stay the same, occasionally they need tweaking. When you are manually chrooting a daemon, everything in the config file should IGNORE the part of the path that will not be visible once you're chrooted, for example /var/log/somelogfile will remain /var/log/somelogfile despite it's new path actually being /chroot/nginx/var/log/somelogfile

Tenha em mente que qualquer daemon que possa ser chroot através do arquivo de configuração não precisará deste conjunto de etapas - o chrooting será feito pelo programa depois que as dependências da biblioteca e os arquivos de configuração relevantes tiverem sido executados. carregado. O que torna a vida muito mais simples.

Uma vez que você tenha feito isso, em teoria você deve estar pronto para rodar o nginx (ou qualquer outra coisa) chrooted. Em seu script /etc/init.d/ para nginx, encontre onde o binário nginx está sendo executado e altere-o para usar o chroot, por exemplo:

$ DAEMON -c $ CONFIGFILE

torna-se

/ usr / sbin / chroot / chroot / diretório / aqui $ DAEMON -c $ CONFIGFILE

Então você pode iniciar o nginx normalmente com seu script init.d. * Se você receber um erro do chroot como "chroot: não pode executar o comando '/ bin / that / actually / exists': Nenhum arquivo ou diretório", então você está perdendo algumas bibliotecas, ou algo mais essencial. Qualquer coisa que faça com que o binário não funcione resultará nesse erro (na verdade, uma caixa de centos minha diz que Operação não é permitida).

Como não tenho pontos de repetição suficientes para postar muitos links, confira www (ponto) securityfocus (ponto) com (barra) infocus / 1694 (protegendo o apache passo a passo) - é um http diferente daemon, são os mesmos passos básicos, pelo menos no que se refere ao chrooting.

Também tenha em mente que suas permissões de arquivo na pasta chroot precisam ser atendidas - basicamente, contanto que o usuário que nginx executa possa ler / lidar com seus arquivos no chroot, tudo ficará bem.

Por fim, como um exemplo de quais tipos são necessários em um ambiente chroot, veja uma lista aleatória de arquivos de um openwall caixa que está executando uma série de coisas chrooted. Estou usando o mysql como exemplo:

localhost!root:/# find /chroot/mysql 
/chroot/mysql
/chroot/mysql/var
/chroot/mysql/var/run
/chroot/mysql/var/run/mysql.sock
/chroot/mysql/var/run/mysqld.pid
/chroot/mysql/var/log
/chroot/mysql/etc
/chroot/mysql/etc/my.cnf
/chroot/mysql/etc/hosts
/chroot/mysql/etc/host.conf
/chroot/mysql/etc/resolv.conf
/chroot/mysql/etc/group
/chroot/mysql/etc/passwd
/chroot/mysql/etc/my.cnf.orig
/chroot/mysql/etc/nsswitch.conf
/chroot/mysql/tmp
/chroot/mysql/lib
/chroot/mysql/lib/libtermcap.so.2
/chroot/mysql/lib/libdl.so.2
/chroot/mysql/lib/libc.so.6
/chroot/mysql/lib/librt.so.1
/chroot/mysql/lib/libpthread.so.0
/chroot/mysql/lib/libz.so.1
/chroot/mysql/lib/libcrypt.so.1
/chroot/mysql/lib/libnsl.so.1
/chroot/mysql/lib/libstdc++.so.6
/chroot/mysql/lib/libm.so.6
/chroot/mysql/lib/libgcc_s.so.1
/chroot/mysql/lib/ld-linux.so.2
/chroot/mysql/lib/libnss_compat.so.2
/chroot/mysql/lib/libnss_files.so.2
/chroot/mysql/lib/libnss_compat-2.3.6.so
/chroot/mysql/lib/libnss_files-2.3.6.so
/chroot/mysql/data
/chroot/mysql/data/mysql
/chroot/mysql/data/mysql/db.frm
/chroot/mysql/data/mysql/db.MYI
/chroot/mysql/data/mysql/db.MYD
[further mysql tables have been omitted]
/chroot/mysql/dev
/chroot/mysql/dev/null
/chroot/mysql/usr
/chroot/mysql/usr/local
/chroot/mysql/usr/local/libexec
/chroot/mysql/usr/local/libexec/mysqld
/chroot/mysql/usr/local/charsets
/chroot/mysql/usr/local/charsets/README
/chroot/mysql/usr/local/charsets/Index.xml
/chroot/mysql/usr/local/charsets/armscii8.xml
/chroot/mysql/usr/local/charsets/ascii.xml
/chroot/mysql/usr/local/charsets/cp1250.xml
/chroot/mysql/usr/local/charsets/cp1251.xml
/chroot/mysql/usr/local/charsets/cp1256.xml
/chroot/mysql/usr/local/charsets/cp1257.xml
/chroot/mysql/usr/local/charsets/cp850.xml
/chroot/mysql/usr/local/charsets/cp852.xml
/chroot/mysql/usr/local/charsets/cp866.xml
/chroot/mysql/usr/local/charsets/dec8.xml
/chroot/mysql/usr/local/charsets/geostd8.xml
/chroot/mysql/usr/local/charsets/greek.xml
/chroot/mysql/usr/local/charsets/hebrew.xml
/chroot/mysql/usr/local/charsets/hp8.xml
/chroot/mysql/usr/local/charsets/keybcs2.xml
/chroot/mysql/usr/local/charsets/koi8r.xml
/chroot/mysql/usr/local/charsets/koi8u.xml
/chroot/mysql/usr/local/charsets/latin1.xml
/chroot/mysql/usr/local/charsets/latin2.xml
/chroot/mysql/usr/local/charsets/latin5.xml
/chroot/mysql/usr/local/charsets/latin7.xml
/chroot/mysql/usr/local/charsets/macce.xml
/chroot/mysql/usr/local/charsets/macroman.xml
/chroot/mysql/usr/local/charsets/swe7.xml
/chroot/mysql/usr/local/share
/chroot/mysql/usr/local/share/mysql
/chroot/mysql/usr/local/share/mysql/english
/chroot/mysql/usr/local/share/mysql/english/errmsg.sys
/chroot/mysql/bin
/chroot/mysql/bin/test
/chroot/mysql/bin/nohup

Um exemplo da configuração de um daemon que pode ser chroot através de seu arquivo de configuração é o maradns:

localhost!root:/# find /chroot/maradns/
/chroot/maradns/
/chroot/maradns/logger
/chroot/maradns/db.[removed]
/chroot/maradns/db.[removed2]
/chroot/maradns/db.[removed3]

Como você pode ver, o maradns não precisou de muito para obtê-lo chrooted (na verdade ele apenas requeria "chroot_dir=" / chroot / maradns "no arquivo / etc / mararc.

De qualquer forma, este tem sido um longo e extremamente desconcertante post direcionado ao software um pouco diferente do que você está usando, no entanto, espero que esta informação ainda seja útil.

    
por 05.12.2009 / 05:02
3

O nginx precisa da raiz para se ligar à porta 80 como processo mestre. Seus processos de trabalho são executados em usuários diferentes (com base na configuração).

Para tornar o nginx chrooted e o php-fpm legais, não é tão difícil - apenas certifique-se de que o nginx tenha acesso ao php-fpm (usando o tcp é mais fácil) e verifique se ele está correto chrooted php-fpm, claro).

Outras dicas de segurança são definir as permissões de arquivo corretamente. Aqui está como eu fiz:

condição:

  • diga que tudo está localizado em / var / www / root
  • arquivos php tem extensão de .php
  • O php-fpm é executado como usuário "php", grupo "php"
  • o nginx é executado como usuário "www", grupo "www"

permissões:

  • todos os arquivos são proprietários do php: www (proprietário "php", grupo "www")
  • A permissão dos diretórios
  • é de 750
  • arquivos php têm permissão de 600
  • todo o resto é 640

Resumindo:

chown -R php:www /var/www/root
find /var/www/root -type d -exec chmod 750 {} \;
find /var/www/root -type f -exec chmod 640 {} \;
find /var/www/root -type f -name '*.php' -exec chmod 600 {} \;

Uma permissão mais precisa pode ser dada, mas essa deve ser fácil o suficiente e não quebrará nada.

    
por 28.01.2010 / 10:15

Tags