ACL vs Capability

TongKe Xue xue at ai.stanford.edu
Mon Jul 3 11:37:12 PDT 2006


I'm not sure if anyone has really thought about that, but I reckon TrustedBSD 
ACLs are easiest to integrate.
Cool. Didn't know about it's existence. According to:
http://www.trustedbsd.org/cap.html
-- Paste --
The reason that these changes have not yet been integrated into FreeBSD is 
that they represent a substantial risk, as they change the superuser 
privilege model, and there have been a number of vulnerabilities in other 
operating systems relating to both implementation and logic errors with 
fine-grained privileges, and this implementation has seen insufficient 
review. Also, the in-kernel API for privilege checking is limited to a 
32-bit or 64-bit privilege mask, which does not offer room for sufficient 
future growth in privileges, or further fine-graining.
-- End --

It seems like DragonFlybsd would suffer from the same problem -- unless 
the decision has already been made to integrate it in. So I'm just curious 
-- if decision has already been made.


The granularity of capabilities is actually per 'object', not per process 
necessarily. You can control virtual memory mappings with capabilities too, 
and that's far more fine-grained than just per process (which would result in 
an 'everything-or-nothing' approach because of per process capabilities).
When a process P wants an access to an object O, ACL's look at the user 
who P is executing as and decide whether to grant access. Capabilities on 
the other hand, will make the decision based on P instead. Correct? I 
don't understand the virtual memory example.

Thanks,
--TongKe




More information about the Kernel mailing list