Re: Media Excitement!

[Cody Hatch <bytejump () gmail com>]

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
> wanted to, you could set up an SE Linux box for a secretary that could
> use an Email program, Web Browser, Printer, and Word Processor.  If she
> went to the wrong website that wanted to exploit her browser, it would
> only be able to do things from the security context you allowed for her
> browser.  It wouldn't have access to her sensitive documents, or her gpg
> keys, or your internal network, etc.  She would be able to open those
> dirty attachments from email and not get compromised with a DDoS zombie
> client.  She would have these protections because what is and what is
> not allowed is clearly defined in the policy, and the policy is
> enforced.

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. It wouldn't have even been a question of what
resources her browser has access to, but the fact that it misbehaved
and tried to overwrite a return pointer and execute code would have
caused it to be clobbered. No policy to maintain.

The complexity of RBAC is its biggest weakness. Securely administering
something as simple as an internal and external firewall on an
enterprise level is a nightmare, let alone what resources various
applications can access on a per-machine basis. How would one manage
that on a large scale? Sure, theoretically it's a good idea, and it's
fairly easy to implement on one's own computer, but managing something
like you're describing on a large scale would be awful.

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, and they prevent the actual exploit
rather than attempting to contain it (though they do work to contain a
successful exploit).

A great example, in my opinion, would be something like below, where
an attacker is trying to compromise an Apache server with the various
protections I'm describing.

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

In the beautiful ASCII diagram above, the goal of the attacker is root
on the web server. Assume he knows of some 0-days against Apache and
the Linux kernel it's running on. First, he must get his exploit to
work through mod_security without knowing that mod_security is
running. If you aren't familiar with the mod_security project, check
it out at www.modsecurity.org - it's very nice.

Assuming he gets his attack past mod_security, he then must get the
code to execute on a system protected by PaX/grsecurity/ProPolice.
Obviously, his canned 0-day isn't going to work so he's got to modify
it to work on _this system_. It also will not be a one-shot exploit
but will require some trial and error.

Assume he gets his 0-day past PaX/grsecurity/ProPolice and compromises
Apache on the box. Now he's sitting in a chroot jail and is the
"apache" or "nobody" or "www" user (whatever the Apache daemon is
running as). He now must break out of the jail and elevate his
privileges to that of root.

Assume he has a 0-day for Linux that should allow him to elevate his
privileges (probably some stupid setuid binary - there are tons of
them in a standard Linux distro - and this is where roles are
fantastic). What he doesn't know is that the Apache binary is also
contained by systrace policies and grsecurity ACL's, effectively
limiting what it can do outside of the chroot jail as well as within
the jail. He now must do more trial and error to get past those
policies while still facing the restrictions imposed upon him by
PaX/grsecurity/ProPolice. Again, a successful one-shot exploit isn't
terribly likely.

If the attacker can get past all of these protections and successfully
root the box, hats off to him and I enter early retirement. However,
at every step the attacker's trial-and-error attacks would be logged,
allowing the security team to respond.

The beauty of the above example is that the only thing requiring any
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.

RBAC certainly has a place and can enhance this, though I'm not sure
how much it enhances it compared to the systrace policies and
grsecurity ACL's. My point is that the above scenario requires little
ongoing administration, while maintaining RBAC policies across an
enterprise, especially on workstations, would be difficult to say the
least.

While I don't speak for pageexec, I believe this is what he had in mind.

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