[EMAIL PROTECTED] wrote:
On 26 Apr 2006 at 10:58, Joshua Brindle wrote:
I don't agree that specific attack vectors are required to determine
whether a model is broken.
specific examples of attack are needed for people with less specialized
knowledge in security (i might say, sometimes even for the specialists)
but with the ability to understand a demonstration. sometimes the attacks
one thinks of as 'breaking the model' are actually the result of the
misunderstanding of the model.
That is silly. The model is to essentially sandbox apps. The problem is
that the sandbox is leaky due to the abstractions being used (eg.,
paths). There is no way to determine that the policy you wrote is
actually being enforced, and again, escalating privileges and increasing
the potential for misuse.
The reasons I think the model is broken are pretty clearly laid out in
the url's posted.
there's not a *single* word about system calls in those posts. second,
those 'pretty clear' reasons are anything but, i'll get to that on the
blog itself though.
once again, model != implementation. I was talking about the model, and
these particular posts weren't targeting systrace at all, as far as I
knew this crap was off the radar.
There are also others for this specific implementation. It is a dire
problem to facilitate non-security aware/minded users to add rules to
the policy dynamically.
my feeling is that you're looking at the whole world with a rather limited
view, everything that doesn't fit the selinux view (as that's what this is
no.
all about, isn't it) must necessarily be wrong. maybe before you do that,
you should ask the authors about their threat model, use cases, etc and
then evaluate their solution. fwiw, selinux is just as broken as anything
else out there, down to the fundamental design level, and it's even more
dangerous than other systems (gives false sense of security) as pretty much
everyone sells it as The Solution for security. nothing could be further
from the truth, so let's not look down on others just because they don't
fit your particular (mis)understanding of security.
That is absolutely false. If some person sells selinux as The Solution
that is one thing, I have never said and will never say that SELinux is
any kind of end all for security.
The false sense of security is also a lie. Unlike path based systems the
SELinux policy can be analyzed and precise (and non-ambiguous) access
vectors can be observed and removed if necessary. Further, you are
confusing the policy with the mechanism. The mechanism is not
fundamentally flawed at the design level (you didn't mention any design
flaws, and I don't know of any, speak up if there are)
The fact is on _ANY_ path based system you cannot tell if the policy you
wrote (and are running) is actually being enforced by the system because
of ambiguity of filenames. That is not the case with SELinux. Some group
of people blindly trusting the policy we give them is one thing but you
are attacking the very mechanism which is total bullshit.
"If I don't push yes this won't work", these systems have been shown
time and time again to fail.
any specific examples?
and my quiz of the day: how's blindly turning audit2allow into a policy
better than blindly clicking yes on a messagebox? it's not yet that's
And have I ever suggested this? This is not about what someone on
#selinux says, this isn't about what Red Hat says (even though they
don't advocate doing that blindly). The system can be abused, no shit.
Giving users the opportunity to abuse it easier is not a good thing.
exactly what some suggest as a fix for selinux denials. look here for
an example: http://www.linuxsecurity.com/content/view/120837/49/ and
I don't care what some random person says is the way to write policy.
That is NOT what we advocate and that is irrelavent to the discussion
(or we could start talking about how horrible learning mode is, your
choice..)
you can google for more. i'm not saying that user interaction is a good
or bad idea, but i am saying that this cannot be the reason for objecting
against systrace as it applies to selinux as well.
Who cares? I can write 500 pages about blindly using learning mode to
write "least privilege" pages, that doesn't make it right or
representative of the developer community for that particular system.
Try again.
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.
maybe you should give examples here as well, so that the systrace people
can elaborate.
umm, its pretty obvious, want a picture? here:
SELinux:
attacker --> kernel DAC/capability checks --> selinux access checks -->
capabilities granted.
systrace:
attacker --> systrace --> capabilities granted.
it's funny that you mention these as i just came across them and was
going to post a rebuttal to many of your claims. do you want them here
on the list or on the blog (it will probably take a few days until i
have enough free time though)?
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.
you have specifically mentioned apparmor and grsec, and not exactly with
flattering words (not that i expected something else from you but still,
what's with the link to the '6 dumbest ideas' rant by Ranum, which fwiw,
has also been rebuked on the dailydave list?).
Sorry, apparmor isn't even in the same class as grsec in terms of the
security it provides, I probably shouldn't have coupled them like that :)
as a reminder, you kicked off with the following:
An Anti-Pattern is a commonly reinvented bad solution to a problem. In
security there are lots of these, The Six Dumbest Ideas in Computer
Security outlines several that are fairly common but I’m going to go
into detail about one in particular that several semi-popular security
mechanisms adopt.
umm, "rebuked".. if you want to call it that, claiming that "hacking is
cool" is hardly compelling. The ideas on that page are good pointers in
general for security systems, I never saw anything claiming the actual
points were inaccurate *shrug*
if that's not an invitation for a flamewar, then i don't know what is.
but then, you asked for it, we'll see how smart you(r) selinux folks are.
I have no desire to get into a flameware (or the energy/time).
Professionally grsec, apparmor, systrace are irrelavent, the people I
deal with need analyzable policies and labeled objects (you can make fun
of CC requirements all you want but it doesn't matter in the least bit).
Personally I'd like to help security in general. Fedora has SELinux
enabled by default and protects several daemons by default. This is
clearly a win for security, MAC in a general use OS is unheard of, we
are breaking new ground here.
Incase you forgot hardened *does* support grsec, RSBAC and SELinux.
grsec is in no way a second class citizen, when people come to the
channel with problems I try to help them, I don't tell them they are
stupid and need to switch to SELinux. I even suggest that people who
have very lightweight security needs use grsecurity. In practice (eg.,
normal systems, normal people, etc) grsec can be very effective. My blog
posts are about security philosophy (as i stated in the first post) and
best practices. As you, and I know security is 100% about tradeoffs.
Sometimes the more secure solution is not the best for the situation.
I'm not sure what "you asked for it, we'll see how smart you(r) selinux
folks are" is suppose to mean, is that a threat? Are you going to make
fun of us on blogs and mailing lists?
--
gentoo-security@gentoo.org mailing list
