svn commit: r193332 - in head/sys: kern netatalk netinet rpc security/mac

[Robert Watson]

On Wed, 3 Jun 2009, Pawel Jakub Dawidek wrote:

>>   Add internal 'mac_policy_count' counter to the MAC Framework, which is a
>>   count of the number of registered policies.
>>
>>   Rather than unconditionally locking sockets before passing them into MAC,
>>   lock them in the MAC entry points only if mac_policy_count is non-zero.
>>
>>   This avoids locking overhead for a number of socket system calls when no
>>   policies are registered, eliminating measurable overhead for the MAC
>>   Framework for the socket subsystem when there are no active policies.
>>
>>   Possibly socket locks should be acquired by policies if they are required
>>   for socket labels, which would further avoid locking overhead when there
>>   are policies but they don't require labeling of sockets, or possibly
>>   don't even implement socket controls.
>
> This may introduce further overhead if there are few policies that implement 
> socket controls. Then you will have cost of npolicies * lock/unlock. Maybe 
> we could check if there is at least one policy implementing particular 
> socket control and if yes lock the socket in the framework only once? This 
> won't be ideal (there might be socket control that doesn't need to lock the 
> socket), but is good enough for my taste:)

Yes, I've been giving this some thought also.  I reviewed the set of policies 
that implement MAC checks on sockets, and found that they basically fall into 
a few categories:

- mac_biba, mac_lomac, mac_mls - ubiquitously labeled policies that will
   require proper locking of the socket to safely access label data for access
   control decisions.

- mac_test, which uses integer labels on all objects, which doesn't require
   locking, but doesn't hurt for having it.

- mac_portacl, mac_ifoff, mac_partition - no labeling of sockets, but they do
   access socket fields for enforcement, and those fields don't require locks
   because they are static (protocol type, credential, etc).

- mac_stub - no label use because it's a no-op policy.

In general, my feeling is that our users will prefer policies that don't use 
labels on sockets given the above list, and we should optimize for that case 
for the time being.  Likewise, users who are running with multiple policies 
that label sockets will likely be using (mac_biba + mac_mls) in which case 
they've already accepted a significant overhead to label all sockets, packets, 
etc, and will be less likely to notice it.

So at least for now, I'll keep moving in this direction and we can revisit it 
if desired.  My main goal for now is to make sure that options MAC is really 
zero-overhead, and I have a few more changes in the pipeline for the next few 
days to clear up a couple of anomolies I've found in testing so far.

Robert N M Watson
Computer Laboratory
University of Cambridge