Dailydave mailing list archives
Re: Media Excitement!
From: Jack <jack () rapturesecurity org>
Date: Wed, 27 Apr 2005 03:02:01 -0700
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.htmland 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
Current thread:
- Re: Media Excitement!, (continued)
- Re: Media Excitement! robert (Apr 21)
- Re: Media Excitement! pageexec (Apr 22)
- Re: Media Excitement! robert (Apr 22)
- Re: Media Excitement! pageexec (Apr 22)
- Re: Media Excitement! Cody Hatch (Apr 24)
- Re: Media Excitement! robert (Apr 24)
- Re: Media Excitement! Cody Hatch (Apr 25)
- Re: Media Excitement! Jack (Apr 25)
- Re: Media Excitement! Cody Hatch (Apr 26)
- Re: Media Excitement! pageexec (Apr 26)
- Re: Media Excitement! Jack (Apr 27)
- Re: Media Excitement! pageexec (May 09)
- Re: Media Excitement! robert (May 09)
- Laptop Abuse halvar (Apr 25)
- Re: Media Excitement! robert (Apr 24)
- Re: Media Excitement! pageexec (Apr 26)
- Re: Media Excitement! robert (Apr 26)
- Re: Media Excitement! pageexec (Apr 26)
- Re: Media Excitement! byte_jump (Apr 26)
- Re: Media Excitement! robert (Apr 26)
- Re: Media Excitement! Anton A. Chuvakin (Apr 21)