Entrevista com Paulo Laureano

05/01/2003

Paulo Laureano é Administrador de Sistemas de longa data, Director Técnico da empresa Mr.Net e apoiante entusiasta do Software Livre. Quem acompanha o panorama informático nacional já o conhece provavelmente pelo desenvolvimento do Siteseed, das colaborações como editor na Gildot ou de alguma palestra sobre o Software Livre na Minho Campus Party ou noutras conferências.

NM: No teu site pessoal, no artigo "Porquê o OpenBSD?" pode-se ler: "O OpenBSD fica para a minha máquina pessoal, servidores de alta-segurança (Fnac e afins) e firewalls." Esta preferência continua a manter-se hoje em dia?

Paulo Laureano: Sim, sempre que a necessidade de segurança prevalece sobre a necessidade de performance... A falta de SMP e um kernel menos performante que o do seu irmão mais velho fazem com que recorra ao FreeBSD para uma serie de instalações. O OpenBSD permanece a minha escolha a nível de segurança local (i.e. quando há utilizadores com shell) e quando a função primária é mover/filtrar pacotes (i.e. firewalls). Não é a minha primeira opção quando necessito de performance a prestar serviços (i.e. base de dados + apache no caso de sites).

NM: Algumas pessoas apontam o facto das pessoas ligadas ao desenvolvimento por entre as mailing lists terem uma atitude arrogante para quem se está a iniciar na utilização. Tens alguma posição em relação a isto?

Paulo Laureano: Tenho. 100% solidário. Eu entendo que o Unix não é para todos, que os utilizadores de unix devem investigar antes de perguntar, que devem ler os FAQ's, que devem fazer o seu trabalho de casa antes de incomodar o resto da comunidade. Nunca respondo a uma pergunta se a resposta aparece ("de caras") no Google ou está em páginas dos manuais. Isso são serviços para empresas de formação e apoio a administradores de sistemas venderem. Respondo por outro lado à "pergunta esoterica" ou ao "problema que nunca vi documentado". A atitude é basicamente essa na comunidade de OpenBSD e eu identifico-me com essa comunidade.

Acho muito bem, no entanto, que outras pessoas tenham a atitude oposta, respondam a tudo e façam sites de apoio aos utilizadores. Acho bestial que existam pessoas tão generosas e com tanta paciência. Eu venderia esses serviços e acho notável (mesmo!) que os ofereçam.

NM: Já desenvolveste algum software ou utilidade para o OpenBSD que chegaste a disponibilizar publicamente?

Paulo Laureano: Fiz muita coisa que não foi pública (sistemas de sinconização das bases de dados do antigo site da Fnac com os sistemas internos, firewalls que fazem tudo e um par de botas extendendo o antigo ipf, etc) e o Siteseed (junto com uma boa duzia de outras pessoas) que não é "só" para OpenBSD.

Fora isso já submeti várias sugestões de patches para o OpenBSD propriamente dito... alguns foram incluídos com alterações (pelo menos gosto de pensar que a ideia era a minha, mesmo sabendo que pode ter sido outra pessoa a submeter a mesma coisa ou algo de parecido).

NM: Achas que o suporte para multi-processadores (SMP) é uma parte importante que já devia estar totalmente funcional?

Paulo Laureano: Sim. Mas entendo que possa não ser uma prioridade...

Depende do fim para que se utiliza o OpenBSD. Para um firewall ou uma máquina de desenvolvimento interno (staging) o SMP não faz falta. Em muitos sites o SMP não é uma opção por factores económicos, em muitos casos a performance de um só processador chega e sobra. A Fnac, por exemplo, era uma máquina de OpenBSD e nunca teve problemas de performance. Em muitos cenários o "bottleneck" são os discos, as ligações de rede, etc. A capacidade de processamento do CPU não é relevante. A servir páginas estáticas com um 486 enches 10 mbits de banda sem levar a máquina aos 100% de utilização de um único CPU (10 mbits que a maior parte dos servidores não "sonham ter" na Internet). Resumindo: é importante em determinados cenários, irrelevente em outros tantos, mas seria bom haver um bom suporte a SMP. Há pelo menos _DOIS_ projectos para dar SMP ao kernel do OpenBSD que estão disponíveis na Internet e ambos funcionam. Pelo que há essa opção para quem dela necessite.

NM: Acreditas numa politíca de total revelação de problemas relacionados com a segurança ou numa politíca que para proteger os clientes se deve manter escondida também alguma informação?

Paulo Laureano: Acredito que se deve manter escondida alguma informação se isso for de todo possível, durante algum tempo, dependendo da vulnerabilidade e da existência de exploits a circular. O que se passou recentemente com o OpenSSH foi um excelente exemplo: O Theo e a equipa do OpenSSH descobriram o problema, disseram ao mundo que havia extrema urgência em que se fizesse upgrade para a ultima versão, e mês e meio mais tarde fizeram a divulgação dos detalhes.

NM: Que pensas em relação à não-disponibilização de ISO's officiais?

Paulo Laureano: Que é pena o mundo não ser perfeito. É uma forma de uma pequena comunidade de programadores sobreviver trabalhando a tempo inteiro no OpenBSD. Desta forma vendem CD's suficientes para sustentar o projecto, o que é bom, mas a comunidade tem mais trabalho ou espera mais tempo para receber a ultima versão de 6 em 6 meses, o que é menos bom. Se o mundo fosse mais perfeito toda a gente comprava "uma ISO" fazendo o pagamento do valor do CD, sustentanto o projecto com todo o dinheiro em vez de pagar portes de correio e CD's com capas de autocolantes. Mas o mundo não é perfeito, os programadores também pagam contas e esta foi a solução que descobriram para sobreviver. Compro pessoalmente 1 CD por semestre e as t-shirts, na realidade acompanho o CVS e nunca utilizo os CD's excepto em novas instalações.

NM: "Only one remote hole in the default install, in more than 7 years!"
Em que parte do sistema ou software poderá ser o próximo "remote hole"?

Paulo Laureano: Vamos esclarecer uma coisa: os "default install" são extremamente conservadores. Está praticamente tudo desligado e não há muitas hipoteses de haver um remote hole no default install. Isto está tudo correcto mas não é levado suficientemente longe. Na minha opinião não devia vir sequer nenhum serviço activo no default install e o firewall (pf) devia vir com "deny from any to any".

Este tipo de frase não é importante. Francamente até me irrita um bocado. A filosofia de vir tudo desligado (actualmente vem "quase" tudo) por outro lado é importante. O OpenBSD tem o melhor historial de segurança de todos os Unixes. Isso não é devido às opções de default mas sim às auditorias sucessivas de que é alvo. Activar serviços é inevitável se a máquina vai fazer alguma coisa de util.

Eu diria que o caminho correcto é a separação de previlégios, correr chrooted todos os daemons e acabar com a flag de suid dos unixes. Bugs haverá sempre, e alguns serão exploráveis, há que tornar a forma como as aplicações funcionam mais segura. Mesmo com 30 anos o Unix carece de muita evolução e a maior parte das aplicações estão na sua infância. Não há sistemas seguros e o OpenBSD é um bocadinho mais seguro que o resto dos Unixes.

NM: Uma extensão para o gcc chamada propolice foi introduzida no OpenBSD recentemente para detectar buffer overflows em runtime. Serão os buffer overflows os problemas de segurança do futuro?

Paulo Laureano: São um dos problemas de segurança do presente. Há libs para linux que eliminam literalmente a possibilidade de se explorarem buffer overflows (quer na heap, quer no stack). É algo que o sistema operativo deve assegurar. Todos os unix (e os sistemas unix-like) vão ter de evoluir nesse sentido... pelo que eu diria que provavelmente buffer overflows serão rapidamente um problema do passado.

NM: Alguma mensagem para os utilizadores do OpenBSD em Portugal?

Paulo Laureano: Aprendam C e ajudem a escrever o sistema operativo. É simples de seguir as listas e a actividade do CVS... e é particularmente "interessante" para quem se interessa por questões de segurança e por boas práticas de programação.

Entrevista conduzida por Nuno Morgadinho.