|Main Archive Page > Month Archives > linux-security-module archives|
Crispin Cowan <email@example.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:
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html