Re: Media Excitement!

[Cody Hatch <bytejump () gmail com>]

On 4/26/05, Jack <jack () rapturesecurity org> wrote:
> 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 grsec RBAC stuff is pretty cool and, last time I took a hard look
at SELinux, seemed to be less difficult to grasp for my feeble mind.
;-)

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

You're probably right here because DAC is a nightmare to manage.

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

You know, I'm also not a user of RedHat or Fedora, but they are doing
some things that are laudable. ExecShield, even with its failings, is
much further along than any other mainstream Linux vendor is, or even
Solaris 10 for that matter. The SELinux stuff coming up in their
enterprise product is another area where they seem to be far ahead of
the competition. Novell, where are you with SuSE?

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

This is definitely something that must be considered with the above
example, however some risk must be assumed and the idea of an exploit
in mod_security and a ring0 in PaX - at the same time - seems somewhat
far-fetched to me. Your point is completely valid, though.

The above example isn't all that complex, though (my ASCII chart
doesn't do it justice) - at least to me. I am seeing the light a bit
though as far as it being more complex than a role that my Apache
daemon is assigned. That does seem easier to administer. What are the
drawbacks with using SELinux in this scenario, though?

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

Isn't that always more fun - and an easier way to learn?

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

Can you elaborate on your issues with ProPolice? Why was the
complexity of ProPolice unacceptable but the complexity of PaX was?

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

Oh, certainly, but you know that some Perl CGI would be loaded by
someone into a chroot, and then the chroot would be compromised to get
the Perl CGI to work within it. Someone, somewhere has got to be doing
this, and vendors implementing hardened systems have to take this
behavior into account.

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

I understand them, but admittedly they are much more difficult to
explain to the pointy-haired folks than roles, and like I mentioned
before, this discussion is making me see the values of the SELinux
(and Solaris 10 for that matter) role implementation.

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

Point taken.

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

Most definitely.

I definitely need to revisit SELinux and dive a bit deeper. This has
been a very useful conversation from my point of view. What are some
of the drawbacks of SELinux, especially from those who are familiar
with it?

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