David Wagner wrote: > I'm not sure that the capabilities vs. access control lists distinction is > as helpful as one might hope, when we're talking about interposed reference > monitors that are neither part of the subject (e.g., the confined process) > nor part of the object (e.g., the file on disk). > > ACL's are the case where permission-entries are stored with the object. > Capabilities are the case where permission-entries are stored with the > subject. In SubDomain and similar approaches, neither applies, because > permission-entries are stored with the interposed guard entity. At least in the case of SubDomain, this is only partially true. SubDomain's policies, in the human readable form, are oriented at the top level towards programs (subjects). SubDomain's implementation inside the kernel attaches the policy object to task descriptors (processes, again subjects). So while the capabilities are managed by the reference monitor (the LSM module in kernel space) they are still stored with the subject. ACLs, in contrast, necessitate storing policy information with the objects (files). You either do this with an extended attribute file system (as some advanced file system projects are doing) or with creatively named meta-files in the standard file system (e.g. as presented in Robert Watson's talk at USENIX on ACLs and Trusted BSD). You're right that SubDomain capabilities are "in" somewhat from the extreme endpoint of a pure capability system, where capabilities are first class, and can be manipulated by the subjects without invoking the reference monitor. As I said before, SubDomain is not a pure capability system, it's a bastard :-) > You're right that there is also the issue of revocation vs. delegation. If > subjects can delegate their own permissions to others without involving the > OS, then delegation is easy but revocation is hard; if subjects must invoke > the OS to delegate permissions to others, revocation is easy, but > delegation is now controlled. However, this issue is mostly orthogonal to > the capabilities vs. ACL's axis. In practice, almost all ACL systems > provide controlled delegation (and hence revocation is easy), and many > capability systems provide unmediated delegation (and hence revocation is > hard), so in many people's minds, people conflate the two tradeoffs---but I > see no fundamental reason why this must necessarily be so. I think it's inherent to each respective model: Capabilities naturally lend themselves to delegation, while ACLs naturally lend themselves to revocation. Both cases can be overcome with engineering effort, resulting in hybrid models that meet somewhere in the middle. > Sorry to interrupt with the philosophical abstract musings. Back to your > regularly scheduled discussion... I can't think of any way in which the capability/ACL duality impact on LSM: LSM is already storing security blobs with processes (subjects, facilitating capability models) and cannot store security blobs with file objects (because the FS people own that). Therefore, I'm cc'ing and following up to lsm-discussionat_private Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Jul 23 2001 - 22:43:28 PDT