[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sobre particionamento, segurança etc. no manual do Debian.



Da visão de se "trancar" o sistema e se jogar a chave fora, penso que só
se existissem comandos configurados para superusuário para uso de um
administrador com privilégios menores.

O "sudo" pode ser configurado para um conjunto restrito de comandos e
com uso obrigatório de senha, senha esta que pode ser a de um
administrador de menor privilégio.

E estas limitações podem ser programadas também num script, se for o
caso de se usar apenas determinado parâmetro e não se necessitar ou ser
conveniente outros. Dá trabalho e é inflexível por demais.

Eu sei que no GNU/Linux chamam-se de diretórios, falta de costume de
falar deste jeito mesmo de novo mesmo. Com o tempo isto passa.


Em Fri, 30 Mar 2012 15:03:56 -0300
Mauricio Neto <mneto@inbox.com> escreveu:

> Rodolfo,
> acho que não me fiz entender, segundo o texto do Marlon ele postula
> que a senha do root deva ser esquecida ate pelo administrador e se
> necessário for usar um live cd para modificar a senha. Por isso eu
> coloquei este exemplo extremo de um pequena intervenção pode acabar
> sendo uma dor de cabeça
>
> Mauricio Neto
>
> Em 30-03-2012 14:11, Rodolfo escreveu:
> > ".....e você vai avisar ao "chefe" que tem que reiniciar o servidor
> > porque não tem a senha de administrador..."
> > Se o usuário não tem permissão pra ter senha de administrador,
> > muito menos de reiniciar um servidor, acho que protocolos serão
> > quebrados, e alguem vai ser punido.
> >
> >
> > Em 30 de março de 2012 12:45, Mauricio Neto <mneto@inbox.com
> > <mailto:mneto@inbox.com>> escreveu:
> >
> >     Marlon,
> >     Concordo com sua visão extrema de segurança. mas "coisas ruins
> >     acontecem", como falha em placas de rede, um servidor de email
> > que "atola" e coisas por ai. Não vou falar de disco porque neste
> > caso deveriam estar espelhados ou em raid. Mas imagine em um
> > ambiente de produção, atendendo a vários usuários e, você necessita
> > fazer uma intervenção, como por exemplo mudar uma rota de rede,  e
> > você vai avisar ao "chefe" que tem que reiniciar o servidor porque
> > não tem a senha de administrador.... :-)
> >
> >     Segurança e produtividade são os dois pratos da balança
> >
> >     Abraço
> >     Mauricio Neto
> >
> >     Em 30-03-2012 07:53, Marlon Nunes escreveu:
> >
> >         Em Thu, 29 Mar 2012 22:10:17 -0300
> >         Listeiro 037<listeiro_037@yahoo.com.br
> >         <mailto:listeiro_037@yahoo.com.br>>  escreveu:
> >
> >             Olá.
> >
> >             O que vou questionar é algo sem sentido, porém
> > imagina-se uma situação
> >             paranoica, onde algumas coisas podem ser suprimidas por
> >             redundância ou
> >             por necessitar tanto exagero.
> >
> >             Usei algo do manual de segurança e completei com
> > "exageros". Inclusive, se alguém me indicar algo sobre segurança,
> >             alguma lista de
> >             discussão paranoica, sites, de preferência em
> > português, para acrescentar, eu agradeceria.
> >
> >             Li em algum lugar que são obrigatórias e necessárias
> > CINCO partas no
> >             superdiretório / sem serem montadas em outras partições.
> >
> >             /bin, /sbin, /etc, /dev, /lib.
> >
> >             As duas primeiras eu imagino que não será nada escrito
> >             dentro por um
> >             usuário comum.
> >
> >             Da terceira não sei, a quarta será dinamicamente
> >             preenchida e não pode
> >             ter NODEV na montagem. Da quinta também não sei. As
> > outras não-listadas podem ser usadas com partições montadas nelas.
> >
> >             /boot pode conter uma partiçãoprimária e diversos
> > kernels, até de
> >             outras instalações, com GRUB ou LILO escritos em seu
> > boot.
> >
> >             O caso é que em /usr coisas podem ser montadas em
> >             read-only, /var
> >             e /tmp não precisam de suid setado, mas precisam
> >             read-write. Etc. etc.
> >             observações do maual de segurança.
> >
> >             Indo mais além, sob determinadas circunstãncias,
> >             determinadas, o
> >             sistema pode rodar montado sem suid setado.
> >
> >             Então, o que queria saber é se há como usar sem travar
> > ou danificar o
> >             sistema /bin e /sbin como read-only etc. com mount
> >             remontando/transferindo ou algo com menos cara de
> >             gambiarra. Em tempo
> >             de inicialização.
> >
> >             E como pode ser feito para se rodar o que se necessita
> > na inicialização podendo estar com NOSUID, NODEV, NOEXEC etc.
> >             setados no
> >             sistema de arquivos.
> >
> >             Cortando TODAS as gorduras como partições com permissões
> >             desnecessárias, tirando poder de root que não será
> > usado etc.
> >
> >             É para lacrar o sistema e jogar a chave fora, rasgar a
> >             senha root,
> >             esquecê-lo e ser feliz! E se necessário for, usar um
> >             sistema live para
> >             mudar a senha.
> >
> >             Fechar o root mesmo para ninguém consegui-lo, se não há
> > como. E se conseguirem um usuário simples, não poderão encher
> >             muito o
> >             saco.
> >
> >             Talvez para a maioria com mais visão sejam absurdos,
> > exceto as recomendações do manual Debian, mas eu pensaria mais ou
> >             menos em como
> >             se trancar uma porta com sete fechaduras.
> >
> >             Como nunca "calejei" um sistema, estou à procura do que
> > é melhor para
> >             o máximo de segurança. isto incluiu ler o manual Debian.
> >
> >             Se vai servir prá algo, não sei, mas depois de resover
> > isto, preocuparei-me com criptografia de partições e outras
> >             perfumarias.
> >
> >             Obs: Há muita coisa em Informática, principalmente
> >             Software Livre para
> >             se entender. Segurança não é minha área e até o momento
> >             não tenho
> >             pendido para estes esclarecimentos, por isto este
> > caráter momentaneamente "supersticioso".
> >
> >             Desculpem-me pela extensão e desde já agradeço.
> >
> >             Até mais.
> >
> >
> >         Já que você está pesquisando sobre o assunto e sobre as
> > melhores práticas para segurança de sistemas GNU/Linux, eu
> > indicaria a leitura
> >         de [1] grsecurity e [2] selinux. com certeza você vai
> > precisar deles se
> >         quiser melhor em 90% a segurança por ai. até +
> >
> >         1-http://en.wikibooks.org/wiki/Grsecurity
> >         2-http://selinuxproject.org/page/Main_Page
> >
> >
> >         --
> >         To UNSUBSCRIBE, email to
> >         debian-user-portuguese-REQUEST@lists.debian.org
> >         <mailto:debian-user-portuguese-REQUEST@lists.debian.org>
> >         with a subject of "unsubscribe". Trouble? Contact
> >         listmaster@lists.debian.org
> > <mailto:listmaster@lists.debian.org> Archive:
> >         http://lists.debian.org/20120330075326.33a97973@core.ezeec.com.br
> >
> >
> >     ____________________________________________________________
> >     FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks &
> >     orcas on your desktop!
> >     Check it out at http://www.inbox.com/marineaquarium

(...)

Reply to: