1 |
On Wed, Apr 26, 2006 at 10:01:54AM -0400, Joshua Brindle wrote: |
2 |
|
3 |
> This is no flamewar. The model is broken by my standards. It bypasses |
4 |
> built-in DAC and capabilities in the kernel making it the single attack |
5 |
> vector to gain all access on the system. Compare to grsecurity, rsbac, |
6 |
> selinux which do not bypass kernel access control or escalate privileges. |
7 |
> |
8 |
> Further, the "lets ask the user if they want to allow this" is |
9 |
> inherently flawed. It is a discretionary model, the policy is in no way |
10 |
> analyzable. I suggest you read these articles: |
11 |
> http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/ |
12 |
> http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-based-access-control/ |
13 |
> |
14 |
|
15 |
Thanks for the links. |
16 |
|
17 |
It appears we have different standards. I don't find it "broken" at all while |
18 |
I still see why it's not compatible with yours standards. I can see the |
19 |
design issue maybe, but that's far from considering it "broken" or a security |
20 |
issue imho. |
21 |
|
22 |
This is just a matter of perspective. And anyway one thing are design issues, |
23 |
one is a real security problem. As it is now sys-apps/systrace and/or |
24 |
sys-kernel/systrace are not a security issue from a |
25 |
vulnerability/exploitability POV. So I'm going to keep it there as a |
26 |
standalone thing, regarding Hardened inclusion we'll discuss this (since I'd |
27 |
like to hear other hardened team opinions) and if the team doesn't agree then |
28 |
fine it won't be supported. |
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 |
|
34 |
I completely disagree with this, security critical packages should not go |
35 |
through hardened by default and anyway there is no policy for that. This case |
36 |
is an example of why the policy is broken. I want to provide the *choice* of |
37 |
using/installing systrace, if this doesn't appeal your standards it doesn't necessarily |
38 |
mean it should be removed from the tree (unless it's a security issue, which is clearly |
39 |
not). |
40 |
|
41 |
Btw we are not advertising/documenting this as the perfect security solution, |
42 |
so let's not make a big fuss about a unstable ebuild. This *random* developer |
43 |
(member of the Gentoo Security team) would just like to provide a choice to |
44 |
our users. |
45 |
|
46 |
Cheers |
47 |
|
48 |
-- |
49 |
Andrea Barisani <lcars@g.o> .*. |
50 |
Gentoo Linux Infrastructure Developer V |
51 |
( ) |
52 |
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc ( ) |
53 |
0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E ^^_^^ |
54 |
"Pluralitas non est ponenda sine necessitate" |
55 |
-- |
56 |
gentoo-security@g.o mailing list |