[FUG-BR] falha de segurança na familia BSD -

[Patrick Tracanelli]

Nilson Debatin wrote:
> On Fri, 2007-08-10 at 18:22 -0300, Eduardo Meyer wrote:
>> Interpretação errada. TrustedBSD é a solução, não o problema. Alias,
>> CerbNG também não é o problema, e sim a forma de fazer o wrapping das
>> syscalls, como ele faz. Mesma coisa sobre o Systrace, que por sinal
>> foi portado pra Linux, e no Linux é pior ainda, é vulnerável com ou
>> sem Linux Sec Modules.
> 
> É talvez eu tenha interpretado errado quanto ao Trusted, mas como em
> pelo menos uma das camadas de seguranca que ele implementa ele faz
> auditing de syscalls é bem possível que venha a ser afetado no 
> decorrer da evolucão que inevitavelmente essa vulnerabilidade vai
> sofrer.

Quem faz a auditoria é o BSM AUDIT (options AUDIT), nao o MAC, e apenas 
acompanha o uso das syscalls, passivamente, afim de gerar logs e 
relatorios, e no futuro repassar essas informacoes pra um daemon de 
auditoria distribuida, e entao nao intervem, nao sobrepoe e nao modifica 
comportamento delas, e, principalmente, nao usa wrapping de syscalls. 
Entao acho imporvavel que qualquer trecho do TrustedBSD implique em algo 
diferente de seguranca adicional, ja que sempre que precisar fazer 
alguma coisa, tera os labels das camadas e os diversos modulos do 
framework (principalmente MAC) disponiveis, que é exatamente o que 
aumenta a seguranca. Usar wrapping de syscalls tendo o framework do 
trustedbsd seria no minimo, improdencia (pra n dizer burrice), e essa 
imprudencia provavelmente nao vai ser o proprio Robert Watson quem vai 
cometer (ja que ele quem trabalhou no BSM Audit da Apple e AUDIT do 
FreeBSD).

> 
>> Mas não nos apeguemos as aplicações. Dizer que o problema .e uma ou
>> outra ferramenta tá errado. O RWatson só citou alguns exemplos que ele
>> pesquisou. Se procurar encontra muitos mais. O que está sendo apontada
>> é falha de design e depender de syscall wrapping para impor segurança
>> quando na verdade se abre um enorme buraco para explorar falhas, e
>> principalmente esta sendo apontada a importancia de dispositivos de
>> seguranca em layers e  tambem stacking (empilhamento).
> 
> As aplicacões pouco contribuem mesmo pro problema, o grande culpado
> é o kernel, afinal a coitada da userland só faz chamadas as syscalls.
> Agora que isso é um pepino brabo na mão dos desenvolvedores isso é, e
> aposto que as primeiras solucões vao ser do tipo gambiarra e vai trazer
> uma certa (por enquanto indefinível) degradacão de performance.

Acho que voce tem razao, as primeiras ideias que eu vi no undeadly.org 
pra amenizar o problema, são pura gambiarra hehehe. Por outro lado é bem 
curioso ver como os sistemas são tao diferentes, mesmo sendo todos de 
mesma origem, sendo todos BSD (isso pra tomar conta da nossa cozinha, 
sem ficar olhando o quintal alheio hehe, deixem que solaris, linux e 
windows olhem seu umbigo enquanto nos olhamos o nosso): FreeBSD e Mac OS 
tem frameworks extensivos e extensiveis, bem projetados e seguem um 
padrao (POSIX.1e), enquanto DragonflyBSD, originado do FreeBSD, 
curiosamente nao tem nada disso, e usa message-passing (obviamente fruto 
das pretencoes futuras do sistema quanto a clusterizacao e paralelismo), 
que tambem é eficaz pra resolver o problema, enquanto Net/OpenBSD (um 
derivado do outro) se atem a syscall wrapping (que é mesmo mais comum, 
provavelmente mais simples de implementar e cetamente nao requer um 
framework nem reescrita inteira do SO).

> A solucão é ficar com um olho no OpenBSD, que deve ser o primeiro a
> propor solucões pra isso e com o outro nos exploits que vão sair pra
> ver se afetam os SOs que usamos.

Acho que o OpenBSD é que tem que abrir o olho. Todo um espetáculo em pró 
da segurança, parece o espetáculo do crescimento do Lula, e não investe 
em subsistemas que realmente tornem o ambiente, no mínimo, mais distante 
das primitivas básicas do modelo de privilégios Unix. FreeBSD tem 90% do 
POSIX.1e, com MAC, extattr e a partir do 8.0-CURRENT, fine-grained 
capabilities. Linux tem LSM, que apesar de nao ser um MAC da vida 
(palavras do proprio autor do LSM), e' util e poderoso, e combinado com 
NIDS, ACL e outras coisinhas menos relevantes deram alguma certificacao 
pro Red Hat "trusted" (esqueci o nome dessa versao do produto). Mac OS X 
Leopard eh UNIX 03 e brigando pela mesma certificacao de seguranca que o 
rwatson quer pro FreeBSD. Enquanto OpenBSD parece que ta meio parado no 
tempo, preocupado mais com drivers e documentacao de drivers oferecidos 
por fabricantes, e "o odio aos drivers binarios pra sistemas livres" do 
que com remodelacao de seguranca. E Systrace da vida, segue a mesma 
primitiva do CerbNG, e esse caminho claramente nao parece ser o mais 
apropriado.

Acho que o silencio, ate o momento, do OpenBSD vai direto em encontro a 
um dos lemas do projeto: "Shut up and Code!". Nao e' hora de brigar, 
contestar, ou vir com declaracoes tipicas do Theo. E' hora de ficar 
quieto e desenvolver. Estou torcendo por isso, e espero que se um 
esforco nesse sentido vindo do OpenBSD, seja em conjunto com o Robert 
Watson. Afinal, ele trabalha com os desenvolvedores do Mac OS, trabalha 
com o Chris Wright do Linux Security Modules, trabalha o engenheiro de 
seguranca da Sun (esqueci o nome, preciso consultar no site da fug 
hehe), so pra citar os sistemas que mais pesquisam nessa area, e 
implementa tudo isso no FreeBSD ou porta pro FreeBSD o que é bom em 
outros (OpenBSM Audit, pra citar um). O natural seria cooperacao 
conjunta do Theo tambem. Mas, é só torcida minha ;) Nao acho que isso va 
acontecer...


-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
(31) 3281-9633 / 3281-3547
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"