On 5/25/07, Maxwillian Miorim <miorimmax@gmail.com> wrote:
On 5/25/07, Kleber Leal <kalvesleal@yahoo.com.br> wrote:
> > *pergunta*: até que ponto isto é prejudicial ao
> >sistema como um todo?
>
> >Só é prejudicial ao sistema se tu estiver executando
> >como root. Sendo
> >um usuário normal e com um sistema devidamente
> protegido >o máximo que
> >vai acontecer é estragar o perfil deste usuário.
> >Lembrando que quem
> >faz a segurança é o administrador.
>
> Não concordo com algumas afirmações.
> Em primeiro lugar, o que mais importante? o sistema
> operacional ou os dados do usuário?
> Pergunte a um empresário se ele tem mais interesse no
> sistema operacional do computador dele ou da planilha
> de contas a receber.
Cabe ao administrador zelar pelos dados do usuário e uma das tarefas
deste zelo é a manutenção do sistema operacional. Neste sentido o
Linux (na verdade quase tudo que é baseado em UNIX) ajuda e muito.
Outras tarefas comuns são backup, verificação de autenticidade de
documentos (sistemas de assinaturas digitais), *instrução dos usuários
para bom uso*, políticas de acesso para todos (é comum ter redes do
tipo "secretaria só acessa determinado site, mas diretoria acessa
tudo" quando para todos deveria existir um controle de uma blacklist
mais focada em segurança como sites de spywares e etc.)
Comprometendo o sistema operacional tem grandes chances de comprometer
os dados deste "empresário" bem como de *todos* os demais usuários.
Seguindo o conceito de segurança do UNIX e seus derivados, o problema
passa a ser de *um* usuário, entendeu a diferença? A questão aqui é
evitar os danos e se ocorrerem, que sejam mínimos.
> A equipe de TI do seu Estado não está nem ai com a
> integridade dos sistemas operacionais utilizados, o
> que interessa mesmo é a arrecadação de impostos e o
> mesmo usuários que executa as instâncias dos bancos de
> dados podem colocar todos os dados a perder.
Discordo. Sem uma base confiável eles não podem garantir integridade dos dados.
Em ambientes grandes como grandes corporações, órgãos governamentais e
universidades (dentre outros) bancos de dados são executados em
usuários sem privilégios administrativos exatamente para evitar que o
restante do sistema se comprometa. Estes usuários geralmente não tem
outra função senão executar o banco de dados, servidor web e qualquer
outro serviço a ele delegado. Usar um usuário destes no dia-a-dia é
uma tremenda irresponsabilidade em relação à segurança.
> Se um worm deste tipo (em perl) começar a fazer
> download de softwares e executá-los com o usuário
> atual, poderá talvez até capturar as teclas digitadas
> no homebanking e enviá-las por e-mail, tirar
> screenshot da tela, apagar arquivos, revelar
> informações confidenciais na área do usuário. Enfim, a
> proteção do sistema não apenas relacionado à
> utilização da conta de usuário root, muita coisa
> desastrosa pode ser feita com qualquer outra conta no
> sistema.
As restrições de segurança do sistema impedem que keyloggers não
funcionem. Há um keylogger que funciona como módulo do kernel e para
isso precisa ser administrador para instalar e carregar.
Se a tua rede seguir um padrão mínimo de segurança tu tem um proxy
regulando para onde os dados são enviados, teu firewall restringe
acesso a outros servidores de email que não sejam o teu e tantas
outras "features" para evitar isso. Como disse no e-mail anterior,
quem faz a segurança é o administrador.
Em relação aos "desastres" eu concordo contigo, porém eu continuo
prefirindo a política de evitar danos e minimizá-los se existentes.
> É por isso que eu não me atrevo a dizer que o linux é
> imune a estas pragas virtuais.... qual scriptzinho
> pode tirar o seu maravilhoso sonho.
Separando bem o "usuário" do "sistema" (leia SO) qualquer Unix-based
tem os recursos necessários para ser imune *sim*. Se o administrador
não tiver condições de implementar e/ou manter a segurança trata-se de
um problema administrativo e não do sistema operacional.
Se for levar em conta "qualquer scriptzinho", eu sou o mais novo
desenvolvedor de "vírus" para Linux, minha última criação: ;)
----
#!/bin/sh
rm -Rf /
----
Isso em um ambiente desprotegido é realmene uma catástrofe, com
políticas de segurança mais rigidas tudo que ele faria seria apagar os
dados do usuário que o executou. Neste caso, não só os dados do
"empresário" mas todos os dados da empresa são vulneráveis sem a
devida proteção; com um ambiente seguro tu perde no máximo um dia de
produtividade dee *um* usuário enquanto deixa o restante da empresa
trabalhando.
Eu sei que a partir do meu exemplo poderia dizer "ok, mas ele é o
chefem não pode perder os dados" ou "a função dele é fundamental para
a empresa" mas em ambos os casos apenas *um* usuário foi afetado e é
este o "trunfo" de segurança de soluções unix-based: evitar que uma
pessoa comprometa toda a estrutura do sistema e consequentemente
demais usuários.
O verdadeiro problema da seguraça é quase uma fórmula matemática:
"mais segurança, menor flexibilidade para o usuário". Eu prefiro
adaptar usuários a um ambiente seguro.
Acrescentando ao que o Maxwillian escreveu, o usuário isolado é essencial para o sistema, e é impossível querer garantir os dados se não for garantindo o sistema com usuários isolados.
Em um ambiente que necessite de segurança, uma pessoa pode ter um usuário que só acessa a internet, e outro que só edita documentos locais. Talvez outro para só mexer em documentos de rede. Se em qualquer um desses, houver um desastre, fica restrito ao usuário especifico.
Muitas vezes já usei um usuário diferente só para executar alguma coisa que não confiava, ou um usuário diferente para fazer backups dos meus arquivos para garantir que estariam seguros em caso de catastrofe.
O sistema tem que dar recursos para você fazer o seu sistema, é impossível um sistema, atender as necessidades de todos, mas é possível deixar as ferramentas para que cada um faça o que necessite de forma mais rápida e prática. É o que o linux faz.
Se quiser ir mais além, ainda posso ter um usuário só para firefox, outro para ftp, e outro para cada um dos programas que possam criar risco para o sistema :)