Re: Media Excitement!

[pageexec () freemail hu]

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.

> disclaimer: i dont know alot about the grsecurity rbac stuff, so
> perhaps it can label objects and prevent trojan stuff or something
> similar, im reading the patch now, cause i always used
> selinux for that role.

check out GR_TROJAN and related code.

> 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.

> However selinux is policy driven and can even `manage permission
> for operations on objects' that like things that PaX can export
> to it (wink wink nod nod).

Joshua Brindle implemented the necessary ACL hook into SELinux more
than a year ago, check out the selinux mailing list for the patch
(it won't cleanly apply to the latest PaX versions but it's not hard
to adapt).

> [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.

> 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).

> 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.

> 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.

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave