Crispin Cowan <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
