[Apparmor-dev] Re: File descriptor object capability LSM module. Feasability?

[Mark Seaborn]

Crispin Cowan <crispin at crispincowan.com> wrote:

> The other issue with the object capability model is analyzability.
> Stephen Smalley complained about this in some public setting a while ago
> when someone basically asked for an object capability enhancement to
> SELinux. Stephen is correct, in that with a pure ambient capability
> model, you can analyze the text of the complete system policy, and
> readily determine the maximum permissions that any given entity will
> have under that policy. With an object capability model, the scope of
> access of a given program is determined by what gets passed into it, and
> so you would have to resort to tools to compute the transitive closure
> of all capabilities that *could* be delegated to it.

That is not true in the general case.  If process A and process B can
communicate, process A can delegate any authority it has to process B,
if both processes want to do that.  Putting object-capability support
into the kernel is just a way of making that more efficient and
convenient.  SELinux/Apparmor are no more analyzable than
object-capability systems.

There is only a difference in analyzability if:
 - you decide you're not including malicious programs (i.e. not an
   adversarial model), or
 - you define analyzability so that you're measuring something that
   is not important (permissions) rather than something that is
   (authority).


>           o Show a use case of a real program (not a straw man) such
>             that with the current features, your choice is to either
>             provide a dangerously permissive security policy, or the
>             policy breaks the program.

An e-mail client.  With a static security system, if you want to be
able to use the e-mail program to send attachments, you must grant the
e-mail program access to all of your files in advance, because you
could want to send any file as an attachment.

Regards,
Mark