[GTER] RES: Quagga

[Marcus Andree]

2009/3/31 Joao H L M Silva <jhlmsilva at gmail.com>:

> quando você passar de 160Mb/s com mais de 400k states
> openbsd não vai dar conta
> o motivo é a segurança, como fazer seq number tracking, e ter wrapper
> de syscalls pelo kernel inteiro

Nao apenas isso. Ha mais elementos que devem ser considerados. Um deles,
em maior ou menor grau, dependendo de varios fatores, como o hardware utilizado,
tem a ver com o numero de busy waits presentes nos drivers.

> se você passar de 5k syn/s você vai ver o "syncookies do openbsd"
> jogar sua disponibilidade pro limbo, você vai achar mais rápido correr
> a são silvestre com uma bola de aço amarrada a sua perna ai quero ver
> seu time de métrica justificiar o SLA
>

Creio que a questao principal era seguranca e portabilidade. Quanto `a
disponibilidade,
mais uma vez, prefiro duas maquinas single-core que segurar tudo numa dual.

> sobre segurança, talvez essa conversa pertença mais ao GTS ou outras
> listas, mas deixa eu mencionar alguns fatos:
>
> - openbsd faz segurança de kernel com a técnica de syscall wrapping;
> syscall wrapping NÃO É SEGURO, tanto que você quebra um dos maiores
> recursos do openbsd, o systrace, fácil, com menos de 30 linhas de
> código; outros sistemas de segurança que atuam dessa forma como CERB
> (FreeBSD), Pax (Linux) e partes do LSM (Linux Security Modules) também
> podem, facilmente, ser sobrepostos com syscalls de mesmo nível ou
> inferior, ou seja não valem muita coisa
>

Desculpe, mas o problema do systrace existe desde os primordios da humanidade.
Recentemente, foi trazido a tona em uma das listas do OpenBSD (creio
que a tech@),
Que reproduzo abaixo. A resposta veio direto do Theo, que precisou de um minimo
de edicao para melhor clareza.

> > I guess you should take a look at Systrace:
> > http://en.wikipedia.org/wiki/Systrace
>
>
> This was removed from NetBSD some time ago because it is vulnerable.
> They said it's not only possible to circumvent it, but also gain root
> using it. Is this fixed in OpenBSD somehow?

They freaked out and did the wrong thing.

systrace has a small problem.  It is a very difficult problem to fix
because of the kernel system call argument fetching is spread so
widely.  This problem was documented since the beginning:

BUGS
    Applications that use clone()-like system calls to share the complete ad-
    dress space between processes may be able to replace system call argu-
    ments after they have been evaluated by systrace and escape policy en-
    forcement.

That said, this is not enough reason to entirely delete the code.  It
still has uses.  With the other address space security changes we have
made, the risks from this are subtantially mitigated.  You also cannot
"gain root" except in extremely well crafted situations which are not
real; systrace does not have the ability to "grant root" unless you build
the policy specifically to do such a stupid thing (actually, I am not
certain if our systrace, the original, ever had that deluded ability
of escalation; I think it was added by netbsd).

So a project that does zero about real security issues overreacted --
probably because the code had originally come from here.  Typical.
One can only hope that some issue comes up in openssh, and that they
then delete openssh, too.


> sugiro http://www.watson.org/~robert/2007woot/, sugiro tambem o video
> do rodrigo (bsdaemon) no YSTS 1.0 (tem no ysts.org), e na lista de
> desenvolvimento do LSM
>
> além disso segurança vale pra você na mesma proporção que a
> insegurança pode afeta-lo, então em um roteador contando que o sistema
> que voce usa não possa ser comprometido sem acesso local ou remoto de
> outra forma, tanto faz se é linux, bsd, solaris, cisco...
>

Pra mim, foi impossivel achar um "sistema que nao possa ser
comprometido sem acesso
local ou remoto" com estes termos contratuais... :)
Por via das duvidas, fiquei com o OpenBSD. Ha' um problema com escalabilidade?
Sem duvida. Fique na safe zone da escalabilidade e durma tranquilo.

> -  todas as caracteristicas de segurança do openbsd associadas a
> userland e libs, as implementações do daniel bernstein se mostraram
> mais rápidas e eficientes
> --

Discutivel... Sem falar nas quebras de compatibilidade ou de funcionalidade...

> gter list    https://eng.registro.br/mailman/listinfo/gter
>