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
(...)