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