Ronan, A permissao padrao do /etc somente permite a escrita do usario root e/ou do grupo wheel. Alterar suas permissoes de acordo com sua sugestao equivale a montar esta particao, para os demais usuarios, como "read-only" (ro), acredito eu. Isto significa que, por exemplo, nenhum usuario podera obter os dados armazenados na base de dados de usuarios, shell e home, por exemplo. Quaisquer outras informacoes, como descobrir quem eh o resolver do DNS neste servidor nao podera ser obtido por seus usuarios. Nao tenho certeza se um usuario comum conseguiria trocar de senha. Acho que esta eh uma opcao valida (a utilizo frequentemente) para obter maior confiabilidade em servidores cuja base de usuarios e configuracoes raramente sao alteradas. Montando a particao raiz (/) como read-only obtemos um filesystem imune (virtualmente) a problemas logicos. Se este fosse um servidor cuja base de usuarios nao sofre-se alteracoes, acredito que esta seria uma opcao razoavel. Como, acredito eu, sua expectativa eh que sua base de clientes aumente a ponto de voce necessitar, rapidamente, de um segundo servidor, um terceiro... :) Todavia, nao garante limites e/ou retricoes aos scripts que forem executados no servidor Apache.
Supondo que voce esta utilizando o Apache, hospedando dominios atraves de VirtualHosts, com PHP instalado na forma de um modulo, uma opcao eh determinar os parametros de ambiente que podem e/ou devem ser impostos aos seus usuarios. Pode experimentar estas opcoes para impor certas restricoes a seus usuarios. <IfModule mod_php4.c> php_value include_path ".:/usr/local/lib/php" php_admin_flag safe_mode on </IfModule> <IfModule mod_php3.c> php3_include_path ".:/usr/local/lib/php" php3_safe_mode on </IfModule> Tambem nao eh aconselhado que o seu php.ini habilite a execucao de extensoes ext/posix em um ambiente onde seguranca eh um dos objetivos. Estas restricoes podem ser complementadas por uma classe especifica de login, ajustada para, entre outros aspectos, estabelecer o valor da variavel coredumpsize como zero. Uma serie de tecnicas de acesso nao autorizado podem ser consideravelmente prejudicadas atraves deste artificio. Tambem eh possivel adicionar a sua configuracao de VirtualHost uma diretiva do tipo open_basedir, estabelecendo que cada script PHP seja executado em um ambiente chroot que toma por base a localizacao indicada na variavel DocumentRoot. <VirtualHost www.exemplo.com.br> ServerName www.exemplo.com.br DocumentRoot /www/exemplo [...] <Location /> php_admin_value open_basedir \ "/www- home/exemple.com/:/usr/lib/php/" </Location> </VirtualHost> Esta configuracao, somada a variavel "safe_mode on", restringe a utilizacao de binarios aos diretorios indicados. De outra forma o PHP pode ser configurado para cada VirtualHost indicando diretorios especificos (php_admin_value open_basedir "/home/username/"), restringindo o acesso de cada usuario a apenas a seus arquivos. executando o Apache como o usuario www, por exemplo, e tornando este usuario membro de todos os grupos definidos para cada VirtualHost, nenhum diretorio necessita de premissoes de leitura amplas. Desta forma usuarios nao podem ler scripts php atraves de scripts cgi ou atraves de um acesso shell. Lembre-se que a intrucao safe_mode on inibe certas funcionalidades do PHP, ocasionando erros quando instrucoes PHP como backticks (``), system(), exec(), passthru() sao utilizadas.. Outro jogo de bola completamente diferente eh observado quando utilizamos o PHP para executar CGIs no servidor Apache. Uma opcao para este modelo de execucao eh compilar o Apache com suporte a opcao SuExec. Desta forma eh possivel determinar o usuario que executa os scripts e a hierarquia de diretoios onde estes estao armazenados e os diretorios acessiveis aos scripts, previnindo acessos nao autorizados a areas restritas. Outro caminho possivel eh impor o redirecionamento de CGIs no Apache. As diretivas abaixo podem realizar esta operacao: Action php-script /cgi-bin/php.cgi AddHandler php-script .php Esta opcao indica ao seu servidor que, ao receber uma requisicao como a URL abaixo: http;//exemplo.com.br/minhapagina/teste.html a reescreva na forma abaixo: http://exemplo.com.br/cgi-bin/php/minhapagina/teste.html Para que esta operacao seja possivel compile seu binario PHP com a opcao "--enable-force-cgi-redirect" e estabeleca valores aprorpiados para a as variaveis doc_root euser_dir no arquivo php.ini. Tambem eh possivel determinar o montante de recursos que podem ser utilizados por cada VirtualHost, dificultando a execucao de determinados tipos de exploits, atraves das instrucoes abaixo, ajustando a carga que um VirtualHost pode "empurrar" para o servidor Apache. LimitRequestBody 4096 RLimitCPU 5 15 RLimitMEM 8192 16384 RLimitNPROC 10 15 Lembre-se tambem que estes scripts sao ativos, mas estao restritos a arvore determinada pela diretiva DocumentRoot do Apache. A inclusao da opcao "SymLinksIfOwnerMatch" determina que links simbolicos somente serao seguidos se existir correspondencia entre os "donos" da origem e do destino. A nao inclusao da opcao Indexes inibe a capacidade de obter uma lista dos arquivos de um diretorio que nao apresente um arquivo index valido. Recomendo o livro Professional Apache Security. Emprestei-o semana passada a um amigo e nao me recordo de todas as opcoes indicadas pelos autores. Outra opcao eh o livro Apache Administrator's Handbook. Entretanto, todas as opcoes mencionadas e inumeras outras estao documentadas na Internet. Uma busca no Google deve retornar a documentacao necessaria para uma investigacao mais acurada. Aqui, no RExLab, adotamos estas restricoes na execucao do PHP sem grandes transtornos, apenas uma pequena adequacao dos desenvolvedores eh necessaria, indicando claramente as restricoes em vigor. []'s Luiz Maia Windows: "Where do you want to go tomorrow?" Linux: "Where do you want to go today?" FreeBSD: "Are you, guys, comming or what?"
_______________________________________________________________ Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr Historico: http://www4.fugspbr.org/lista/html/FUG-BR/
