Pensei em alguma coisa que gerasse uma senha de root aleatória e que fosse guardada em armazenamento móvel depois de instalar algum sistema, ou pedir para troca, ou troca periódica etc, ou envio prá algum lugar usando GPG, semelhante etc.
Bem naquela política do "a chave deste cofre não se encontra em poder da empresa".
Ou uma senha "descartável", que é renovada automaticamente após cada uso.
A senha de algum modo só se fica sabendo qual é se for necessário usá-la.
É para ninguém saber, não aparecer em lugar algum, ninguém acessar.
Ideias, ideias. :P
Se é prático e viável, ainda não sei, mas é interessante se
houver ameaça física, embora crackers sejam mais sutis.
Obrigado pelas respostas.
Em Fri, 30 Mar 2012 21:42:41 -0300
Marlon Nunes <mcnunes@gmail.com> escreveu:
> Opa Maurício Neto,
>
> So uma correção, as dúvidas relacionadas não foram questionadas por
> mim e sim pelo "Listeiro 037 listeiro_037@yahoo.com.br".
> Eu somente indiquei links relacionados a sistemas de segurança para o
> GNU/Linux. até mais.
>
> 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
> > >
> > >
> > >
> > >
> > > --
> > > 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/
[🔎] 4F75E324.3010600@inbox.com> > >
> > >
> >
> > ____________________________________________________________
> > FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas
> > on your desktop! Check it out at http://www.inbox.com/marineaquarium
>
>