Andrea Barisani wrote:
<snip>
*sigh*
I thought that this flamewar was dead. Ok, I kindly ask a hardened team
review of this since I strongly believe this is not an issue, systrace is
*not* a broken security model and yes it allows *controlled* privilege
escalation if you configure it that way for removing the setuid but on some
binaries.
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/
If you have an argument to make please show me the technical details about it
and let's discuss it.
It's *not* part of hardened atm anyway and it won't be unless the hardened
team accepts it. It will remain in the portage tree as long as I support it
unless you show me a clear demonstration of your concerns.
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
control mechanisms in the tree, users will have security expectations
that they cannot meet.
BTW even with your concern the ptrace method (which can be entirely tested
userspace) is still useful for debugging/testing, hence the userspace package
has no reason for going away.
As long as its clearly marked as a debugging tool and not as a security
tool.
CC'ing systrace author btw (not subscribed to this list)
Great.
--
[email protected] mailing list
