| 1 |
Andrea Barisani wrote: |
| 2 |
> <snip> |
| 3 |
> |
| 4 |
> *sigh* |
| 5 |
> |
| 6 |
> I thought that this flamewar was dead. Ok, I kindly ask a hardened team |
| 7 |
> review of this since I strongly believe this is not an issue, systrace is |
| 8 |
> *not* a broken security model and yes it allows *controlled* privilege |
| 9 |
> escalation if you configure it that way for removing the setuid but on some |
| 10 |
> binaries. |
| 11 |
> |
| 12 |
This is no flamewar. The model is broken by my standards. It bypasses |
| 13 |
built-in DAC and capabilities in the kernel making it the single attack |
| 14 |
vector to gain all access on the system. Compare to grsecurity, rsbac, |
| 15 |
selinux which do not bypass kernel access control or escalate privileges. |
| 16 |
|
| 17 |
Further, the "lets ask the user if they want to allow this" is |
| 18 |
inherently flawed. It is a discretionary model, the policy is in no way |
| 19 |
analyzable. I suggest you read these articles: |
| 20 |
http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/ |
| 21 |
http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-based-access-control/ |
| 22 |
|
| 23 |
> If you have an argument to make please show me the technical details about it |
| 24 |
> and let's discuss it. |
| 25 |
> |
| 26 |
> It's *not* part of hardened atm anyway and it won't be unless the hardened |
| 27 |
> team accepts it. It will remain in the portage tree as long as I support it |
| 28 |
> unless you show me a clear demonstration of your concerns. |
| 29 |
> |
| 30 |
First it will never be accepted by hardened. Second, I believe that |
| 31 |
security critical packages (particularly access control systems) should |
| 32 |
go through hardened. Random developers *should not* be putting access |
| 33 |
control mechanisms in the tree, users will have security expectations |
| 34 |
that they cannot meet. |
| 35 |
> BTW even with your concern the ptrace method (which can be entirely tested |
| 36 |
> userspace) is still useful for debugging/testing, hence the userspace package |
| 37 |
> has no reason for going away. |
| 38 |
> |
| 39 |
As long as its clearly marked as a debugging tool and not as a security |
| 40 |
tool. |
| 41 |
> CC'ing systrace author btw (not subscribed to this list) |
| 42 |
|
| 43 |
Great. |
| 44 |
-- |
| 45 |
gentoo-security@g.o mailing list |
Archives