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 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
