Re: Media Excitement!

[Jack <jack () rapturesecurity org>]

First off let me say that im not slamming PaX or grsecurity,
in fact when i was doing a selinux/slackware project (that
never really got anywhere, but will again soon) we used PaX
and selinux for our trial with slackware 8.1, and some of the features
of grsecurity are cool, and are missing in selinux (not that i think selinux
should try and do those things, i think they should be seperate from selinux).
                                                                                
On Mon, 25 Apr 2005 17:28:14 +0000
Cody Hatch <bytejump () gmail com> wrote:
> On 4/25/05, robert () dyadsecurity com <robert () dyadsecurity com> wrote:
> > I would argue that discretion in the hands of the novice is more
> > complicated than using a MAC/DTE machine for pre-agreed usage.  If you
> > ...
> 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, assuming its capable to stop all other
attack vectors (not really likely from just a injectable code protection standpoint), as
far as i can tell PaX is going to be mandatory by nature (i never enable sysctl stuff)
and everything else that PaX isnt touching is still DAC (totally ignoring the grsec rbac stuff,
i dont know enough about it to say anything really).

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.

> The complexity of RBAC is its biggest weakness. Securely administering ...

actually one of the thing rbac is good for (well not to talk about rbac over the
irbac type in selinux) is taking away the complexity of DAC into something manageable,
using logical roles, and RBAC is Mandatory by nature anyhow.

> grsecurity, PaX, ProPolice, systrace - those are all things that do
> not need constant babysitting. Once you get a working baseline, your
> work is pretty much complete

Thats kinda the idea i think redhat is going with for the selinux on those machines, they are
trying to make it non-intrusive by creating a `unconfined' domain. Can't say im a personal fan
of the idea, i run strict on my laptop for example (nor do i use redhat) but i think its working
for people, as they likely dont have any idea that they are using selinux until they notice they
cant share the gpg keys with the internet via some cgi bug or perhaps even because of configuration
errors. I personally applaud redhat for actually trying to look out for the security of users and
taking such a step in direction that they did, other vendors should look at them as leaders in that
area.

> and they prevent the actual exploit ...

nope. they can prevent it depending on the vulnerability, or otherwise make it very hard to
exploit in practice. 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). 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).
I really prefer the seperation of policy/mechanism in that respect.                  

> Attacker -> mod_security -> PaX/grsecurity/ProPolice -> chroot ->
> PaX/grsecurity/ProPolice -> non-root user -> PaX/grsecurity/ProPolice
> -> systrace -> root on the box

Ok, so how do you model the assurance of this? It sounds like it would be non-trivial.
I mean sure, it sounds like a pain to get though all that, but what if you dont have to
follow those steps cause of attacks on all the extra code that you just added in the layers?
[Random Example]
would it be so shocking to exploit mod_security and then use PaX kernel bugs to get ring0
memory access? 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
http://www.mitre.org/tech/selinux/
http://www.tresys.com/selinux/
                                                                                                                  
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.
                                                                                                  
> code to execute on a system protected by PaX/grsecurity/ProPolice.

Hey you know some people use syslog inside ProPolice when the stack is trashed right?
I mean, it sounds like a bad idea to start doing that in a damaged process (from a broad
perspective). And who knows how all those things interact with one another, i mean
when we did the slackware/selinux thing we tried using PaX and ProPolice (both are cool
projects) but i just couldnt stand by the complexity of execution flow during certain
cases with any sort of assurance, and i certainly didnt have time to investigate that
so I decided that ProPolice was out and we would only use PaX.

> [IN THE CONTEXT OF CHROOT] privileges (probably some stupid setuid binary -

If you throw setuid binaries into chroot you are doing something wrong i think, normally
you would use some interface exported by the kernel to gain control in that case.
                                                                                                                  
> administrator maintenance are the mod_security filters, and those
> would likely be fairly static. grsecurity ACL's and systrace policies
> would stay quite static and could be populated from a test server or
> something. PaX/grsecurity/ProPolice are all inherent in the kernel or
> gcc-compiled code and require zero maintenance.

Like i said before, if you had certain goals, like you really value protection
of certain things, how would you understand all the different protection mechanisms
to see how it protects those in a simple fashion?
                                                                                                                  
> My point is that the above scenario requires little
> ongoing administration, while maintaining RBAC policies across an
                                                                                                                  
Try understanding (the big picture) the security of a bunch of DAC ACL's all over a bunch of
different machines and tell me what is less work. What if the users change ACL's then how do things
stand then? cant really understand that anymore, you really have to guess.
                                                                                                                  
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.

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