[EMAIL PROTECTED] wrote:
On 26 Apr 2006 at 13:38, Joshua Brindle wrote:
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.
is there any particular reason you're avoiding answering my (Andrea's,
for that matter) requests for specific attack examples?
it's my observation that you as well as many other selinux advocates
often try to stay at some superficial theoretical level of 'attacks'
as if that meant anything in the real world. it means nothing, so
please try get down from that 'high horse' and answer the questions.
I do not believe that specifying a specific vulnerability is required
for a model to be broken. I also do not actively try to break systems
(penetrate and patch methodology) to decide if they are broken, any
theoretical problem with the model is exploitable in the worst case
scenario, that is enough. There is nothing 'high horse' about it, do you
think people that build skyscrapers have to see the natural disasters
that will destroy the buildings first hand? No, they have models for
everything, the sky scraper itself, the possible 'attacks', etc.
<snip>
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.
what is it that you say about selinux then? clearly, you must have an
opinion about its place in the world of security solutions. i.e., is
there (according to you) a situation where say apparmor or grsecurity
provide better security (you get to define what security means in that
situation) than selinux? i'm all ears ;-). you realize that if you
cannot provide such a situation then you'll have effectively confirmed
my statement.
what best suits your needs depends on your security needs. I've always
said this in hardened. I have no need to create imaginary situations,
I've suggested to many people in #gentoo-hardened that grsecurity might
meet their needs better than other solutions.
<snip>
you suggested that systrace should be rejected (among others) because
it allows the user to (re)define the policy based on feedback from the
access control mechanism. all i pointed out was that the same applies
to selinux as well (and it does happen in real life too) yet you're
not suggesting its removal. you can't have it both ways.
There is a huge difference between a policy loaded into the kernel that
is mandatory at all times (and can be modified when necessary) and a
policy that is in userspace, is entirely dynamic, and pops up with a
dialog when a new access attempt happens. Clearly the policy has to
change to the environment, however in general MAC policies should not be
changing at run time. Since the systrace author has said that systrace
is not and does not want to be MAC this might be a non-issue. Just as
long as anyone using systrace knows they aren't using a mandatory access
control system.
umm, its pretty obvious, want a picture? here:
SELinux:
attacker --> kernel DAC/capability checks --> selinux access checks -->
capabilities granted.
systrace:
attacker --> systrace --> capabilities granted.
and? this is not an attack vector, this just describes how things
work at some conceptual level. an attack is where you demonstrate
how you exploit the above mechanism to gain privileges that weren't
otherwise granted to you by the systrace policy. note that i'm not
saying that such an attack doesn't exist, it's just that you have
yet to demonstrate one.
Eh? that _is_ an attack vector. you are asking for a PoC exploit which
is not something I'm interested in that sort of thing at all. Again, you
do not need a reproducible exploit to have a broken model.
<snip>
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 :)
oh the tears of joy... can't believe you actually said that.
more seriously, more on the blog.
I'm not sure why you can't believe I said that. grsec has several
advantages over apparmor, the primary one probably being that it can
actually do access control on the entire system rather that an
app-by-app basis (which apparmor explicitly limit themselves to)..
apparmor decided to build simplicity into their model instead of making
their model extensive and simplifying the policy writing/generation.
grsecurity has similar deficiencies, such as IPC. The reason is that
grsecurity specifically targets system/app integrity and not information
flow. The claim from the grsec author will be that IPC isn't a real
attack vector, and in practice it might not be for more systems but
there are many systems that are very sensitive to information flow and
need IPC protection. grsecurity wouldn't be sufficient for those
systems, it may be for others.
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*
start here: http://marc.theaimsgroup.com/?l=dailydave&m=112638071303189&w=2
and please tell me you're not running with a+x.
The answer to that email is simple. You don't need an access control
matrix of a million elements if you have equivalence classes (something
widely used in SELinux), see
http://securityblog.org/brindle/2006/03/23/the-myth-of-least-privilege-or-why-we-love-equivalence-classes/
the a+x in $PATH argument is a strawman, anything you run is under your
privilege level (whether that's the DAC uid or the MAC domain (or
however it is implemented))
<snip>
actually, the folks who wrote CC are very clever in my opinion, they
have clearly understood what information security is all about and it's
not their fault that many 'experts' of our time sell their concepts to
completely wrong markets.
Glad to hear it...
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.
i was saving this for the blog, but since you've brought it up...
you've just proved how dangerous spreading false sense of security
is. the targeted policy you're talking about does not give any real
security and coming from a self-described expert on selinux, it's
really disheartening to see as you should know better than that.
Once again, you are confusing policy and mechanism. Just because the
targeted policy doesn't restrict everything on the system doesn't say
anything at all about the mechanism. Second, the targeted policy never
claims to protect everyone from everything, quite the opposite, the name
"targeted" pretty clearly states that certain things are restricted.
Now, the difference between the selinux targeted and other systems is
that with the targeted you can actually analyze the policy and ensure
that the targeted domains can't affect the integrity of the rest of the
system, which is impossible with path based systems.
Also, where have I ever said that I'm an expert on security or selinux?
I do not appreciate blatant attempts to misinform or discredit people,
don't do that.
it is a bandage for the utter usability mess that selinux is and
'everyone' had complained about. practical example, what does
restricting nscd by a policy help (and i'm generously ignoring the
possibility of exploiting a kernel bug in a two stage attack) when
an exploit can just go for an unconfined application (plenty of them
left)? so yeah, a clear win and breaking new ground there... no.
On recent targeted systems most, if not all, network daemons are
confined. Its pretty obvious that an "unconfined" application is... wait
for it... not confined! wow, I'm very glad that you can use a
dictionary. I don't think anyone expects unconfined applications to be
... well.. confined. If they do they've been grossly misinformed, I take
no credit for anything 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 think you misunderstood me. i don't care what opinion you hold about
grsec or apparmor or whatever as much as i care about not spreading
false sense of security. you drew a clear and obvious line between
selinux and the rest of the world ("grsec/apparmor implement one of the
dumbest ideas in security", that's what you stated effectively), and
that's simply not right so you will have to defend your opinion or eat
those words, your choice.
I think you misunderstanding. I claim that path based access control is
flawed for all the reasons I've listed (which you haven't refuted) at an
ideal and philosophical level. There are a number of practical and
technical issues with this as well (see the LSM list over the last week
or so...) But I haven't talked about those at all, I'm not sure where
you are coming from here.
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 effsective.
although i wasn't talking about grsec per se, but now you made me curious.
what the heck is 'lightweight security'? and how come that a system
implementing one of the dumbest ideas in security can be effective?
effective at what? being dumb? or perhaps, providing 'security'? what
would that 'security' mean then and why cannot selinux provide it?
Once again, security is about your requirements and possible tradeoffs.
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?
you already pulled that feat off, so i'm left with the task of putting
the pieces of the puzzle together for all to see.
Ok, have fun with that. I'm going to be gone after today until next week
so don't misconstrue my lack of reply as assent.
--
[email protected] mailing list
