1 |
On Wed, Apr 26, 2006 at 12:59:03PM -0400, Joshua Brindle wrote: |
2 |
> Well, systrace is path based so you can apply all those arguments |
3 |
> directly. I don't understand what you mean by systrace is not MAC, what |
4 |
> is it? It has a policy, it enforces access control. I guess choosing to |
5 |
> run the app under it directly makes it discretionary. It still has all |
6 |
> the issues that my blog such as ambiguous paths, problems in shared |
7 |
> directories, etc. |
8 |
|
9 |
Did you bother checking how systrace checks/applies the path? (the tone isn't |
10 |
accusatory here, I didn't do it yet myself, but still we can't flame it without |
11 |
knowing its implementation, this is not as easy to evaluate as you try to put |
12 |
it design-wise). Admitedly you don't know much about systrace implementation, |
13 |
would you kindly check into it and see how it *really* works before judging it? |
14 |
Not saying that this should make you change your mind but it would probably be |
15 |
best and it would allow a much more constructive feedback. |
16 |
|
17 |
Neils, any comments about this? |
18 |
|
19 |
> What you are doing in essence is making all binaries setuid by allowing |
20 |
> privilege escalation. Think about it, setuid tells the linux kernel to |
21 |
|
22 |
"all binaries" ? I never said that I'd apply this to all binaries, systrace |
23 |
is discretionary so to speak... |
24 |
|
25 |
> change the uid when this app is run, so you "remove" the setuid bit and |
26 |
> let systrace escalate the capabilities by bypassing the kernel, this is |
27 |
> not different from just having the binary be setuid and then only |
28 |
> allowing whichever caps it needs and is more dangerous since there is a |
29 |
> single layer controlling capabilities for an attack vector. |
30 |
> |
31 |
|
32 |
systrace "becomes" a kernel feature, systrace "bypassing" the kernel makes no |
33 |
sense to me, but I guess this is a semantic issue... |
34 |
|
35 |
This is just moving the all-permissive setuid concept (which I might say can be |
36 |
arguably a kinda broken/insecure thing) to a syscall acl framework. |
37 |
|
38 |
> Neither grsecurity nor SELinux allow any kind of bypass of standard |
39 |
> linux kernel permissions. They cannot lower the security level of the |
40 |
> system whereas systrace can by granting capabilities that processes |
41 |
> would not have had otherwise. |
42 |
> |
43 |
|
44 |
Systrace can lower the security level of the system if *you* configure it to |
45 |
do so as *root* (which could do that anyway), this is just shifting the sec |
46 |
model from 'setuid lets the process run as root but we "jail" it with MAC' to |
47 |
"we remove setuid and we selectively allow kernel_side what it can do". |
48 |
|
49 |
Unless you are really dumb in defining policies I can't see how this could be |
50 |
heavily mis-used / compromised. |
51 |
|
52 |
Neils, Method: all feedback is welcome. |
53 |
|
54 |
Cheers |
55 |
|
56 |
-- |
57 |
Andrea Barisani <lcars@g.o> .*. |
58 |
Gentoo Linux Infrastructure Developer V |
59 |
( ) |
60 |
PGP-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc ( ) |
61 |
0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E ^^_^^ |
62 |
"Pluralitas non est ponenda sine necessitate" |
63 |
-- |
64 |
gentoo-security@g.o mailing list |