On Wed, Apr 26, 2006 at 10:01:54AM -0400, Joshua Brindle wrote:
> This is no flamewar. The model is broken by my standards. It bypasses
> built-in DAC and capabilities in the kernel making it the single attack
> vector to gain all access on the system. Compare to grsecurity, rsbac,
> selinux which do not bypass kernel access control or escalate privileges.
>
> Further, the "lets ask the user if they want to allow this" is
> inherently flawed. It is a discretionary model, the policy is in no way
> analyzable. I suggest you read these articles:
> 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/
>
Thanks for the links.
It appears we have different standards. I don't find it "broken" at all while
I still see why it's not compatible with yours standards. I can see the
design issue maybe, but that's far from considering it "broken" or a security
issue imho.
This is just a matter of perspective. And anyway one thing are design issues,
one is a real security problem. As it is now sys-apps/systrace and/or
sys-kernel/systrace are not a security issue from a
vulnerability/exploitability POV. So I'm going to keep it there as a
standalone thing, regarding Hardened inclusion we'll discuss this (since I'd
like to hear other hardened team opinions) and if the team doesn't agree then
fine it won't be supported.
> First it will never be accepted by hardened. Second, I believe that
> security critical packages (particularly access control systems) should
> go through hardened. Random developers *should not* be putting access
I completely disagree with this, security critical packages should not go
through hardened by default and anyway there is no policy for that. This case
is an example of why the policy is broken. I want to provide the *choice* of
using/installing systrace, if this doesn't appeal your standards it doesn't
necessarily
mean it should be removed from the tree (unless it's a security issue, which is
clearly
not).
Btw we are not advertising/documenting this as the perfect security solution,
so let's not make a big fuss about a unstable ebuild. This *random* developer
(member of the Gentoo Security team) would just like to provide a choice to
our users.
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
