Re: Media Excitement!

[byte_jump <bytejump () gmail com>]

On 4/26/05, robert () dyadsecurity com <robert () dyadsecurity com> wrote:
> What is meant here is that whom ever is evaluating or designing the
> security mechanisms that are to be used by the system should be aware of
> and formally analyze how all of the pieces work together.
>
> I do not consider SE Linux to be bolted on.  It comes as a core
> component of some distributions (such as redhat), and the kernel pieces
> are a part of the main kernel src tree.  The SE Linux documentation also
> says that it is not currently a complete TCB implementation, but I
> believe it to be a great start.

A kernel patch is "bolton on" and SELinux is a kernel patch, just as PaX is.

> This is a two part answer:
> A) Being able enforce policy even when software modules are exploitated
> is a great benefit.  Without these policy violation containment
> capabilities, a software module compromise has the potential to escalate
> into a complete system compromise.

But again, why not prevent the exploitation all together while still
protecting the process via systrace policies or grsecurity ACL's,
which are both human readable. A policy analysis tool isn't required.
Heck, both of them even have "learning mode" for creating policies.

> The concept is simple.  Software has had, and will continue to have
> bugs.  If you can design a resonably secure base, you won't have as many
> problems from compromised software modules.  That's a lot more sane of
> an approach than telling people to "just write bettere software".  When
> kernel level bugs do come about (and I believe they will), in most cases
> having sufficient access to even attempt to exploit the bug will be very
> difficult, and in some cases not possible depending on the policy and
> the type of bug discovered.

You believe kernel-level bugs will "come about"? I believe there have
been upwards of 20 security patches to the 2.6 kernel just this year.
That's very scary. How's the policy enforcement mechanism going to
work when an exploit works within the confines of the kernel?
Remember, it doesn't prevent the buffer overflow/format string
exploit/etc. but seeks to contain a successful compromise within the
parameters of the policy. If the exploit happens  at kernel-level, all
bets are off. PaX/spp can prevent the exploitation of the kernel
itself, not just seek to contain it afterward.

> Even most windows users have an easier time using windows than they
> would installing/administering windows.  The fewer choices you have to
> make as a novice end user, the better.  If I didn't know any better, why
> should I be asked if 69.25.27.173 should be allowed to connect to me on
> port 139?  I don't want anything to break, I'm just going to say yes and
> continue to check out that snazzy new britney spears screen saver.
>
> The "pain in the ass to learn" was from an administration perspective.
> The limited discretion being "easier to use" was from an end user
> perspective.  Apples and Oranges.

PaX doesn't care whether I some IP tried to connect to port 139. Isn't
that what a firewall is for? Now, depending on the exploit, PaX will
help prevent something that gets past the firewall, and
grsecurity/systrace policies can contain the process' attempts to
overstep its bounds.

> It means that after the compromise, the exploit is still limited inside
> the context of the web browser, normally more limited than the role of
> the invoker of the web browser.  Depends on the policy, but in my policy
> it means that the web browser (and the exploit) can do what it needs to
> do to function as a web browser.  It can't spawn new programs, access
> the sound card, access files other than it's cache, etc.  Very fine
> grain controls, but I kept that example simple.

But why not just give the web browser the access to API's and system
calls that it needs? grsecurity and systrace can say, "You're only
able to make the following system calls and listing the contents of
~/.gpg isn't one of them. You can only list the contents of the
following directories..." and then rather than just let them list
those directories, PaX/spp enforce appropriate behavior on those
allowed system calls, memory mappings, etc.

I intend on digging a bit deeper with SELinux, but I have serious
concerns with the scalability of it. When I'm hearing that I'll need
to take _years_ to understand SELinux, there's too much complexity.
When I hear that I need to change everything that I've learned about
security in order to understand it, that's not a good sign.

It's also not a good sign that policy analysis tools exist to tell me
when I have what they say is an accurate policy. Why aren't the
policies human-readable? How much do you trust those policy analysis
tools? I'm pretty paranoid...

Everything I'm hearing says "complex" and "error-prone" from an
administrative standpoint.

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