Raphael, 2015-12-25 3:00 GMT-02:00 Raphael Bastos <[email protected]>:
> Casfre jones, desculpa ser chato, mas há um erro conceitual ae. Não > existem opções de "segurança". Segurança é um sentimento, uma sensação. O > que existem são defesas que aumentam nossa sensação de segurança. :D > :-) Sim, mas essa sensação de segurança é o resumo daquelas opções. Depois que se junta os cacos, se percebe o vaso, embora quebrado e colado. Essa questão das opções, de colar mais um pedaço aqui, mais um artifício ali, mais uma diretiva de segurança lá, mais ..., me lembra a colocação do Wietse, sobre o uso de TLS no Postfix. Quando li pela primeira vez, fiquei intrigado, mas ele acaba tendo razão. A assinatura dos módulos do Kernel acaba sendo mais uma opção, mais um "pedaço de código" (isso sem julgar o mérito de ser positivo ou negativo, bom ou ruim etc). Um dia desses, eu acabei tendo que ler a colocação dele novamente. :-) WARNING By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on thousands and thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into Postfix. [http://www.postfix.org/TLS_README.html] > Sobre o trabalho que dá em manter mais esse nível de defesa que discutimos > (modulos assinados) é a lei da vida. Segurança se obtém em camadas de > defesa, e quando mais camadas, mais trabalho pra se gerenciar o todo. É > foda huahuauahuahaua > Por isso me veio a questão: mais código, mais procedimentos, mais uma coisa para "dar defeito", mais uma coisa para manter, mais uma coisa para defender, mais uma camada ... Faz tempo que eu tenho pensado em quanto isso escala, até onde isso vai, quanto mais "código auxiliar" será desenvolvido para fechar aquela brecha, consertar aquele bug, contornar o novo problema que surgiu quando resolvemos o problema antigo. Quanto mais procedimentos, maior a chance de falha. Se pensarmos no que Wietse citou, a perspectiva é de termos mais novos bugs a cada "pedaço" que "colamos" no sistema. Sim, vamos acabar no velho dilema: se não for assim, não se desenvolve. Mas até onde isso escala? Eu sempre penso na filosofia original que orientou o desenvolvimento do UNIX e no que aconteceu ao longo da existência dele. No site do Bell Labs (ou era da AT & T?) tinha um link com a história completa, mas depois que reformularam o site, ela "sumiu" (ou eu não achei onde deixaram). Também faz tempo que não procuro. Naquela filosofia falava da simplicidade, do código enxuto, da especialização de cada aplicativo, dos pipes, do streaming "universal" ASCII entre os processos (saida | entrada) etc. Um dia desses eu tive que configurar o nsswitch no Slackware, para fazer uma autenticação via OpenLDAP (na verdade, para atender ao Samba, mas faz parte - nesse caso, por uma série de razões, não cabia a opção de AD). Para isso funcionar é necessário instalar o nssldap. E, nessas libs, há um bug, para o qual já existe um patch e que acabei por descobrir quando pesquisei algo no Slackbuilds. Instalei o smbldap-tools também. Para o smbldap-tools funcionar foi necessário instalar um monte de módulos do Perl e ainda o Kerberos. E o curioso, ainda pensando nos "pedaços" é que um módulo do Perl depende de outro, que depende de outro ... Se pensar bem, para ter aquele domínio funcionando, eu tive que "colar" no sistema mais um monte de código, além do que já estava lá. Ué, mas isso tudo para fazer o Linux se comportar como um controlador de domínios Windows? Sim, é. Mas e a segurança disso tudo? Bem, mais processo administrativo, mais brecha para monitorar, mais coisa para quebrar e por ai vai. :-) > Abração, e bora nos falando. Fazia tempos que eu não discutia com alguém > aqui na br-under que fizesse perguntas tão inteligentes e pertinentes. Eu > que agradeço a atenção e a prosa. :D > Também tenho achado produtivo. Eu hoje mal acho tempo para ler estudar sobre Linux (nem consigo mais acompanhar o Slackware :-) ), mas também sinto falta de tratar de assuntos técnicos, mudanças, evoluções, rumos, acontecimentos. Nessa prosa já apareceram alguns itens sobre os quais eu nem pensava mais (como trocar o kernel sem reboot, por exemplo - ainda não gosto da ideia). Agora, escrevendo tudo isso, me lembrei do pessoal do OpenBSD tratando sobre os bugs que apareceram no OpenSSL e na forma como eles olham para esse situação do desenvolvimento. Será que o caminho é desenvolver, desde a primeira linha de código, já pensando em segurança e em não quebrar? Quanto mais eu penso, mais eu acho que o caminho está na simplicidade, no código enxuto. Mas como fazer frente às tantas exigências do mercado e de um cotidiano "louco", mantendo tudo simples é sim um desafio. Obrigado. Cássio -- GUS-BR - Grupo de Usuários de Slackware Brasil http://www.slackwarebrasil.org/ http://groups.google.com/group/slack-users-br Antes de perguntar: http://www.vivaolinux.com.br/artigo/Como-elaborar-perguntas-para-listas-de-discussao Para sair da lista envie um e-mail para: [email protected] --- Você está recebendo esta mensagem porque se inscreveu no grupo "Slackware Users Group - Brazil" dos Grupos do Google. Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para [email protected]. Para obter mais opções, acesse https://groups.google.com/d/optout.
