On Wed, Apr 26, 2006 at 10:58:17AM -0400, Joshua Brindle wrote: > [EMAIL PROTECTED] wrote: > > > >it'd help the discussion/review (which is what Andrea asked for) if > >you/others were more precise and cited specific attacks. generic hand- > >waving of 'this is broken' doesn't help it. this is not to say that > >i disagree with your opinion (fwiw, you and spender are on the same > >side for once ;-). > > > >
thanks :) > I don't agree that specific attack vectors are required to determine > whether a model is broken. The reasons I think the model is broken are > pretty clearly laid out in the url's posted. There are also others for > this specific implementation. It is a dire problem to facilitate > non-security aware/minded users to add rules to the policy dynamically. I re-read your blog entries and I still fail to see how's systrace affected by this. So just assume that I'm Dumb (tm) and please show me a implementation-specific example of this, also consider that systrace is *not* a MAC and it doesn't want to be one, we are systracing processes explicitely here. > "If I don't push yes this won't work", these systems have been shown > time and time again to fail. And, like I already said, bypassing > in-kernel DAC and capability restrictions means that there is now a > single attack vector to gain all system privileges. This means systrace > actually *removes* a layer of security from the system, which is clearly > a bad idea. It can only if you don't know how to configure/use it, which is something that applies to SELinux, grsecurity, RSBAC and every other system. Feel free to prove me wrong here with examples ;). > >>http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/ > >>http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-based-access-control/ > >> > > > On the blog is fine. Remember that those posts aren't targeting specific > implementations (eg., grsec is not affected by all of the issues listed) > but rather the model in general. I'm curious, why's grsec not affecteced by this? Cheers -- Andrea Barisani <[EMAIL PROTECTED]> .*. Gentoo Linux Infrastructure Developer V ( ) PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc ( ) 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E ^^_^^ "Pluralitas non est ponenda sine necessitate" -- gentoo-security@gentoo.org mailing list
