| 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 |
Archives