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 <[email protected]
<mailto:[email protected]>> 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<[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
with a subject of "unsubscribe". Trouble? Contact
[email protected] <mailto:[email protected]>
Archive:
http://lists.debian.org/[email protected]
____________________________________________________________
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
[email protected]
<mailto:[email protected]>
with a subject of "unsubscribe". Trouble? Contact
[email protected] <mailto:[email protected]>
Archive: http://lists.debian.org/[email protected]
____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your
desktop!
Check it out at http://www.inbox.com/marineaquarium
