Casfre jones, Penso exatamente igual a ti. huahuahahuahua Já viu esse doc sobre unix? https://www.youtube.com/watch?v=tc4ROCJYbm0
Sobre a galera do OpenBSD, é completamente o oposto do Torvalds quando o assunto é segurança, né não? Linus tá se cagando pra segurança do Linux, tanto que é necessária a existência de projetos como grsecurity/selinux/apparmor da vida :D Abs. Att, Raphael Bastos aka Coffnix *====================================================* * Linux Reg. User*: 388431 // *LPI ID:* LPI000214711 *email:~> $* echo "xgvngkrhgyzuyFngiqyzuxk4ius4hx" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge' *Public Key:* 3FBB468B // http://www.hackstore.com.br/coffnix/coffnix-pgp-key.txt *Yaxkin/Gentoo Linux* - http://downloads.hackstore.com.br *Wiki Hackstore* - http://wiki.hackstore.com.br *Área 31 Hackerspace* - http://www.area31.net.br *Kankin/Funtoo Linux* - http://kankin.area31.net.br *====================================================* Em 25 de dezembro de 2015 08:32, [email protected] <[email protected]> escreveu: > 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ê recebeu essa mensagem porque está inscrito 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 mais opções, acesse https://groups.google.com/d/optout. > -- 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.
