1 |
Andrea Barisani wrote: |
2 |
> I re-read your blog entries and I still fail to see how's systrace affected |
3 |
> by this. So just assume that I'm Dumb (tm) and please show me a |
4 |
> implementation-specific example of this, also consider that systrace is *not* |
5 |
> a MAC and it doesn't want to be one, we are systracing processes explicitely |
6 |
> here. |
7 |
> |
8 |
> |
9 |
Well, systrace is path based so you can apply all those arguments |
10 |
directly. I don't understand what you mean by systrace is not MAC, what |
11 |
is it? It has a policy, it enforces access control. I guess choosing to |
12 |
run the app under it directly makes it discretionary. It still has all |
13 |
the issues that my blog such as ambiguous paths, problems in shared |
14 |
directories, etc. |
15 |
>> "If I don't push yes this won't work", these systems have been shown |
16 |
>> time and time again to fail. And, like I already said, bypassing |
17 |
>> in-kernel DAC and capability restrictions means that there is now a |
18 |
>> single attack vector to gain all system privileges. This means systrace |
19 |
>> actually *removes* a layer of security from the system, which is clearly |
20 |
>> a bad idea. |
21 |
>> |
22 |
> |
23 |
> It can only if you don't know how to configure/use it, which is something |
24 |
> that applies to SELinux, grsecurity, RSBAC and every other system. Feel free |
25 |
> to prove me wrong here with examples ;). |
26 |
> |
27 |
What you are doing in essence is making all binaries setuid by allowing |
28 |
privilege escalation. Think about it, setuid tells the linux kernel to |
29 |
change the uid when this app is run, so you "remove" the setuid bit and |
30 |
let systrace escalate the capabilities by bypassing the kernel, this is |
31 |
not different from just having the binary be setuid and then only |
32 |
allowing whichever caps it needs and is more dangerous since there is a |
33 |
single layer controlling capabilities for an attack vector. |
34 |
|
35 |
Neither grsecurity nor SELinux allow any kind of bypass of standard |
36 |
linux kernel permissions. They cannot lower the security level of the |
37 |
system whereas systrace can by granting capabilities that processes |
38 |
would not have had otherwise. |
39 |
|
40 |
>>>> http://securityblog.org/brindle/2006/03/25/security-anti-pattern-status-quo-encapsulation/ |
41 |
>>>> http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-based-access-control/ |
42 |
>>>> |
43 |
>>>> |
44 |
>> On the blog is fine. Remember that those posts aren't targeting specific |
45 |
>> implementations (eg., grsec is not affected by all of the issues listed) |
46 |
>> but rather the model in general. |
47 |
>> |
48 |
> |
49 |
> I'm curious, why's grsec not affecteced by this? |
50 |
> |
51 |
grsec's access control is affected by many of them. Most grsec users |
52 |
don't use the access control, however, they use the other protections |
53 |
(the 80% attack vector thing..) |
54 |
-- |
55 |
gentoo-security@g.o mailing list |