[FUG-BR] Off-Topic: Recomendação de livro sobre ZFS
Caros amigos, sei que é um off-topic, mas gostaria de recomendar um livro a todos aqueles que estão querendo iniciar ou se aprofundar no ZFS e, como eu, já está cansado de pegar uma dica aqui e outra ali, tudo espalhado. O livro é: FreeBSD Mastery: ZFS (IT Mastery) [1] Gostei bastante pois o livro traz um exemplo atrás do outro, com várias formas de se utilizar o ZFS, os prós e os contras de cada situação. obs: Só para constar, o Allan Jude foi um dos que escreveram o man page do ZFS. []´s Edinilson [1] http://www.amazon.com/gp/product/0692452354 ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Ajuda com Sudoers
Valeu pelas dicas vou fazer novos testes e fazer as alterações sugeridas. Assim q tiver um resulto volto a postar. Abraço 2015-07-10 12:36 GMT-03:00 Patrick Tracanelli : > > > On 10/07/2015, at 09:46, Patrick Müller > wrote: > > > > Bom dia galera > > > > Estou precisando de uma ajuda para configurar uma permissão de sudo. > > > > Tenho um script A com as seguintes permissões ---s--x—x que recebe como > > parâmetro um outro script B com permissão rwsrwxrwx, até aí está > > funcionando bem. > > > > O script A tem o seguinte conteúdo > > > > #!/bin/sh > > > > chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1 > > > > chmod 4777 /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1 > > > > > > > > O script B tem o seguinte conteúdo > > > > #!/bin/sh > > > > echo senha | pw mod user usuario -h 0 > > > > > > > > Bem simples para a troca de senha. > > > > > > > > Na configuração do sudoers eu tenho > > > > > > > > Funciona, mas pelos meus critérios de segurança é péssimo. > > > > www ALL=(ALL) NOPASSWD: /bin/sh > > > > > > > > Acredito que para o que eu quero seria uma opção melhor, mesmo ainda > sendo > > um grande risco para segurança. > > > > #www ALL=(ALL) NOPASSWD: /bin/sh /caminho/scriptA.sh > > A simples mudança do PATH antes da execução fará com que chown e chmod > seja qualquer coisa que o “atacante” deseje. Então sempre que for fazer > shell script mais critico, se acostume a usar PATH completo pros comandos, > /usr/sbin/chown, /bin/chmod, etc. Declarar seu próprio PATH no corpo do > script também não resolve ja que o ambiente pertence ao escopo do usuário e > ele faz o que bem entender, redefine, destroi, ignora. > > Faz o seguinte, no sudores coloque sempre o caminho completo pros comandos > que quer permitir e controle os argumentos pro comando. Ou seja > aparentemente você não quer liberar /usr/sbin/chown quer liberar apenas: > > /usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/[A-z]* > > Teste exatamente o que quer liberar e coloque uma regex esperta > controlando os argumentos variáveis :P Abuse da negação no sudo, se for o > caso: > > /usr/sbin/chown -R root > /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/[A-z]*, !/usr/sbin/chown -R > root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/nao_pode > > Nunca libere o seu shell script como um todo, ao invés disso o shell > script deve usar o sudo, e por sua vez path completo, ignorando/dispensando > o PATH existente: > > #!/bin/sh > unset PATH > /usr/local/bin/sudo /usr/sbin/chown -R root > /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/algumacoisa > > Se quiser ter ainda mais controle, faça o usuário www fazer ssh pra > localhost e libere no sudo a execução pra esse outro usuário: > > #!/bin/sh > unset PATH > ssh -i /caminho/pra/chave sudouser@localhost "/usr/local/bin/sudo > /usr/sbin/chown -R root > /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/algumacoisa” > > Você tem mais controle, tem auditabilidade, pode impor limites no ssh, > controle de acesso, pode usar chave com passphrase e o ssh-agent pra > permitir a automação do processo, só sendo necessário digitar o passphrase > quando subir o serviço httpd por exemplo, vai juntar 2 fatores de > autenticação (ter a chave e saber o passphrase), enfim melhora o ambiente > consideravelmente e seu controle. Mas você pode achar demais “tudo isso” só > pra permitir um chown e um chmod ;) Se avaliar que a criticidade não é > tanta, esqueça o ssh e faz o resto, da foco na declaração explícita do que > você quer e não quer liberar no sudoers. > > O proprio man sudoers tem mais exemplos nessa linha de liberar regex > explicitamente e bloquear exceções à regex: > > peteHPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd > root > > %opers ALL = (: ADMINGRP) /usr/sbin/ > > Boa diversão :D > > > > > > > > > > > > > Quem puder avaliar os riscos disso e me ajudar eu já agradeço. > > > > > > -- > Patrick Tracanelli > > FreeBSD Brasil LTDA. > Tel.: (31) 3516-0800 > 316...@sip.freebsdbrasil.com.br > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Ajuda com Sudoers
> On 10/07/2015, at 09:46, Patrick Müller wrote: > > Bom dia galera > > Estou precisando de uma ajuda para configurar uma permissão de sudo. > > Tenho um script A com as seguintes permissões ---s--x—x que recebe como > parâmetro um outro script B com permissão rwsrwxrwx, até aí está > funcionando bem. > > O script A tem o seguinte conteúdo > > #!/bin/sh > > chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1 > > chmod 4777 /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1 > > > > O script B tem o seguinte conteúdo > > #!/bin/sh > > echo senha | pw mod user usuario -h 0 > > > > Bem simples para a troca de senha. > > > > Na configuração do sudoers eu tenho > > > > Funciona, mas pelos meus critérios de segurança é péssimo. > > www ALL=(ALL) NOPASSWD: /bin/sh > > > > Acredito que para o que eu quero seria uma opção melhor, mesmo ainda sendo > um grande risco para segurança. > > #www ALL=(ALL) NOPASSWD: /bin/sh /caminho/scriptA.sh A simples mudança do PATH antes da execução fará com que chown e chmod seja qualquer coisa que o “atacante” deseje. Então sempre que for fazer shell script mais critico, se acostume a usar PATH completo pros comandos, /usr/sbin/chown, /bin/chmod, etc. Declarar seu próprio PATH no corpo do script também não resolve ja que o ambiente pertence ao escopo do usuário e ele faz o que bem entender, redefine, destroi, ignora. Faz o seguinte, no sudores coloque sempre o caminho completo pros comandos que quer permitir e controle os argumentos pro comando. Ou seja aparentemente você não quer liberar /usr/sbin/chown quer liberar apenas: /usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/[A-z]* Teste exatamente o que quer liberar e coloque uma regex esperta controlando os argumentos variáveis :P Abuse da negação no sudo, se for o caso: /usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/[A-z]*, !/usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/nao_pode Nunca libere o seu shell script como um todo, ao invés disso o shell script deve usar o sudo, e por sua vez path completo, ignorando/dispensando o PATH existente: #!/bin/sh unset PATH /usr/local/bin/sudo /usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/algumacoisa Se quiser ter ainda mais controle, faça o usuário www fazer ssh pra localhost e libere no sudo a execução pra esse outro usuário: #!/bin/sh unset PATH ssh -i /caminho/pra/chave sudouser@localhost "/usr/local/bin/sudo /usr/sbin/chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/algumacoisa” Você tem mais controle, tem auditabilidade, pode impor limites no ssh, controle de acesso, pode usar chave com passphrase e o ssh-agent pra permitir a automação do processo, só sendo necessário digitar o passphrase quando subir o serviço httpd por exemplo, vai juntar 2 fatores de autenticação (ter a chave e saber o passphrase), enfim melhora o ambiente consideravelmente e seu controle. Mas você pode achar demais “tudo isso” só pra permitir um chown e um chmod ;) Se avaliar que a criticidade não é tanta, esqueça o ssh e faz o resto, da foco na declaração explícita do que você quer e não quer liberar no sudoers. O proprio man sudoers tem mais exemplos nessa linha de liberar regex explicitamente e bloquear exceções à regex: peteHPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root %opers ALL = (: ADMINGRP) /usr/sbin/ Boa diversão :D > > > > Quem puder avaliar os riscos disso e me ajudar eu já agradeço. -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Ajuda com Sudoers
Bom dia galera Estou precisando de uma ajuda para configurar uma permissão de sudo. Tenho um script A com as seguintes permissões ---s--x—x que recebe como parâmetro um outro script B com permissão rwsrwxrwx, até aí está funcionando bem. O script A tem o seguinte conteúdo #!/bin/sh chown -R root /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1 chmod 4777 /www/src_www.lamce.ufrj.br_ssl/sistemav3/pws/$1 O script B tem o seguinte conteúdo #!/bin/sh echo senha | pw mod user usuario -h 0 Bem simples para a troca de senha. Na configuração do sudoers eu tenho Funciona, mas pelos meus critérios de segurança é péssimo. www ALL=(ALL) NOPASSWD: /bin/sh Acredito que para o que eu quero seria uma opção melhor, mesmo ainda sendo um grande risco para segurança. #www ALL=(ALL) NOPASSWD: /bin/sh /caminho/scriptA.sh Quem puder avaliar os riscos disso e me ajudar eu já agradeço. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
