Re: Media Excitement!

[Jack <jack () rapturesecurity org>]

On Wed, 27 Apr 2005 04:49:11 +0100
pageexec () freemail hu wrote:

> On 25 Apr 2005 at 22:28, Jack wrote:
>
> > > grsecurity and PaX do not rely on DAC to do what they do. In your
> > > scenario the exploit of the secretary's browser would have been
> > > prevented and logged.
> >                                                                                 
> > not really, if its a buffer overflow sure, but PaX isnt going to stop the trojan property
> > of DAC, so in a sense it still has DAC properties,
>
> PaX explicitly does nothing for the filesystem, rather, it controls
> runtime code generation (which is one way of exploiting a memory
> corruption bug). preventing trojans is a different thing.

I was saying that too, i was also saying that things that were not pax had to use DAC still (i
was ignoring grsec or anything else that might be there, thats obviously something else). The fact
that PaX totally ignored other stuff is the reason i did use PaX with selinux, it would have been
silly to use grsec and selinux (not that it doesnt cause the tree to be littered with rejects to even
try for fairly straight forward reasons)

> > Non-executable would be an operation on an object, the object would
> > be heap memory, or whatever, and the permission is hard-coded to deny,
> > not a separation of policy and mechanism, sadly (in your example).
>
> in PaX policy and mechanism are nicely separated, it's just at the
> level where it actually makes sense. doing memory access rights
> enforcement on a per memory region is pointless (considering the
> PaX threat model and the security goals), what you want is per-process
> (per-address space) policy instead, and that's exactly what PaX has.
> the policy comes from the ELF header or an ACL system, enforcement
> is in the VM, all separate.

Well ok, another point was that if i had to mark elf headers, or sysctl things
then my policy overlaps to some degree, because i have to allow things to be written to
in my selinux policy, and if chpax can write to the X server for example, to change things
and i have dri enabled, then that would cause a nasty problem of anyone being able to run chpax
would have a path to kernel memory, ugly. the point is is that i prefer the separation to be in one
place.

> Joshua Brindle implemented the necessary ACL hook into SELinux more
> ...

Thats exactly what i was hinting at.

> > [Random Example]
> > would it be so shocking to exploit mod_security and then use PaX kernel
> > bugs to get ring0 memory access?
>
> question is of course whether you can do each step without runtime
> code generation and/or whether you can do the second step without
> having write access to the filesystem (which is not an unheard-of
> policy for certain network facing code). i have yet to see such a
> multi-stage, no-code-injection (and dare i say 'generic') exploit
> in real life or just as an academic exercise.

It sounds like a challenge, ill take a look, though. Without the code-injection its obviously next to
impossible, but thats what makes it sound like a fun excercise. Another thing that stands out too, aside
from program bugs, is configuration errors, those seem like they would be hard to prevent, selinux doesnt
care much if it is a program error or a configuration issue, it just enforces policy, but creating policy
automaticly will have the same issue then (with selinux).
 
> > i prefer simplicity, no need to stack stuff like that, its too complex,
> > alot of exploits take advantage of all the layers of complexity in software,
> > seems like this isnt considering that.
> >                                                
> > For a good contrast look here, you can download tools that will
> > let you understand if your policy helps you meet certain security
> > requirements. obviously if you had 40 different things going on these
> > tools wouldnt be as usefull ;]
> >                                                
> > http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/rhlcommon-section-0104.html
>
> and you call this *less* complex than deploying grsec/ssp? something
> must be seriously wrong with complexity if you need extra tools (read:
> more complexity and potential bugs) just to tell you what the policy
> you cooked up actually achieves (which implies it's not human
> comprehensible since if it was, you wouldn't need the analyzer tool
> to begin with).

Where are the tools that allow me to make assertions about SSP + grsecurity ... thats the point.
you dont need to run the tools to create a policy. If i want to see all the indirect domain interactions
(by that i mean if this program can spawn this program that can do this and eventually read this file)
creating paths from one domain to a target context i can do so. If i cannot easily make assertions with
grsec + SSP then my point stands, regardless of how silly it sounds. I dont want my assertions to think
that the only way for something to malfunction is memory faults, i just need to know if those interactions
are permitted at all, then i can assume with enough time someone might figure out how to actually do that,
i dont care about that, i would rather just know if those interactions are permitted, and if so, its now
possible for me to disallow that (depending on of course what the issue was, perhaps i would have to remove
software, or functionality worst case).

> > Part of the thing about selinux policies is that you dont have to
> > write them from scratch, they should come with whatever you installed
> > that has selinux, Unless you like to tinker like me and do it by
> > hand, and that can be hard if you haven't done it before, but also
> > alot of fun.
>
> and you still maintain it's less complex than basing your policy
> on grsecurity's learning mode? on another note, i see people using
> 'policy' for two different things: one use is to codify what the
> given application does (so as to not let it do more when compromised
> but still acknowledge the original author's intention), the other
> use is to tell what it should do (based on some theoretical 'grand
> scheme' which is more often than not, pure utopia, but those people
> have to learn it the hard way). in practice, i see the first use in
> grsecurity deployments and the second use when SELinux proponents
> argue about the greatness of mandatory access control. except the
> rest of the world rarely if ever follows their policies which then
> puts a lot of extra work on any distro that wants to deploy SELinux
> and have their userland comply with the 'grand scheme'. if you want
> a practical example, try to create and enforce a policy that forbids
> text relocations or executable stacks and see what a usable system
> you get - policy sounds good in theory, impossible to enforce in
> practice, at least without a lot of work.

Yah i do, cause if the policy is sent with the system, then i dont have to write one, someone else can create
policy, if i need modifications there are tools that can even generate policy that i require for additional
functionality, and in the end i can still generate assertions even if i didnt write the policy.
Obviously creating policy auto-magically is not something i think is a good idea, a good example is if xlock
wants to read shadow, and my `learning mode' allows it to do so, xlock can now reach shadow. i can assert
this and change so its not the case, and in fact, xlock will happily function without reading shadow,
creating a .xlockrc file instead. Plus after an hour or so with vi i was able to adapt the NSA strict policy
for my laptop that is my main interface to the world (for a slackware system of all things, not something
that is supported out of the box). It works for me. Look im not saying grsec sucks, selinux rules. I just
happen to use selinux and not grsec because i think it works better for me, YMMV. Ive run hosting machines
with selinux, and noone even knew they were running selinux, they just were permitted to do what the normally
did, its not that dynamic in my case it turns out, they still see the folders, plop in the files and the
web server still can serve content. The problem it turns out is admins who know nothing about selinux, just
want it to go away, i cant argue with that, the fact that they want to do all sorts of silly things without
learning selinux is not something i can easily fix. Perhaps someone else can come up with a solution for that
i dont know, I think people are even trying to do this, by abstracting the policy, but i think this leads
to gaping holes, but its a trade off with granularity and ease of use if someone is not willing to learn
the policy i think.

> > Side Note: Also ive heard people slam LSM cause it exports hooks
> > for rootkits. i think this is kinda lame because honestly, if you
> > can write to the kernel or kernel memory, who cares how hard it
> > is at that point, the damage is done.
>
> if you want to backdoor a particular machine then it's not much
> of a difference (since you can just dump the kernel memory and
> find all the static addresses you need, although having symbols
> makes all this still faster). if you want to write a generic
> backdoor that works on every 2.6 distro kernel in existence,
> then you'll find some of those symbols quite handy (all depends
> on what you want your backdoor to accomplish of course). where
> LSM symbols also help is the depth of the kernel code that you
> get *reliable* access to, else you'd have to resort to disassembly
> and code matching, not an exact science as any commercial windows
> vendor that patches ntoskrnl in memory (for one reason or another)
> would tell you.

Point taken, i can understand having lsm (more so for people who arent really using
it, but have it) can be some nice leverage, however i was thinking of a single machine.

-- 
jack@\314.\10.\214.\244
vap %rqv\avap %roc\achfu %rfc\anaq %ny,0k20(%rpk)\aqrp %rfc\aqrp %rpk\avap %rfv\avap %roc
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave