Re: SELinux, was Re: X11 -> Root? (Qubes square rooted)

[travis+ml-dailydave () subspacefield org]

On Wed, Sep 01, 2010 at 04:42:03PM -0700, travis+ml-dailydave () subspacefield org wrote:
> For those who the MAC debate, here's my recollection:

Forgot a few, or rather neglected to mention them, because I have no
good response, and am acknowledging the argument by omitting a
response.  I'm responding here in the interest of fairness:

Pro: MAC policies are complex because what you're trying to do is complex.
Anti: So you're saying MAC is complex because MAC is complex?
Pro: I guess so. ;-)

I don't have a good way to defend this, but it seems to me that, in
general, the more fine-grained your protections, and the more tightly
you wish to bound the maximum allowable permissions for an app, the
more you're going to have to write.  Inheritance, abstraction, and
templates could offset some of this difficulty - possibly.  There is
definitely room for growth in this area.

Trade-offs between simplicity and security might be made; for example,
Android gives read/write access to certain objects in the same
permission, and separately in others.  Alternately, these could
be macros of some kind (e.g. O_RDWR = O_READ | O_WRITE).

But yes, I don't really have any justification for this other than it
seems to be so (to me).


Pro: MAC is more powerful than DAC and could replace it entirely
     in certain situations (e.g., a single-user system)
Anti: MAC still needs DAC (it is not a more fundamental primitive).
Pro: Not sure; I'd like to hear examples.

Anti: The implementation is code, and therefore may introduce vulns.
Pro: Yep.

Anti: An average sysadmin may not be able to define the maximum allowable
      permissions required by an app.
Pro: Maybe it should be a speciality, as writing firewall or
     NIDS/NIPS/AV sigs or sendmail rules are.  Having written policies
     myself, the complexity seems drastically overstated, and claiming
     that it's too hard somewhat undermines your own authority on the
     subject.  Writing secure software may be hard, but that doesn't
     mean it makes a bad goal.

There may be other good points I have forgotten.

Nevertheless, I do not consider myself a zealot; it is just a tool,
not a silver bullet, and not one that I use at the moment.

I can think of a number of unaddressed problems:

0) What permissions should, say, a python interpreter have?

1) The maximum allowable permissions (at any point at runtime) may far
exceed the permissions it needs *right now*, just as I may need to
call execve() some time, but maybe not right now, from on the stack.

2) A program may still do significant damage without exceeding its
allowable privileges, just as an intruder doesn't usually need to be
root to send spam.

3) The policy language needs improvement.

4) There should be a mechanism for learning the required permissions,
   perhaps while in a test environment.

*) There are, of course, threats it does not address; kernel bugs,
bugs in the design, hardware attacks, logic flaws, social engineering,
resource abuse, attacks against the CPU (e.g. F00F), ad nauseum.

But nobody familiar with security should be surprised by the fact that
a proposed security mechanism doesn't address all the possible threats.
-- 
It asked me for my race, so I wrote in "human". -- The Beastie Boys
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john () subspacefield org to get blacklisted.

Attachment: _bin
Description:

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