svn commit: r193332 - in head/sys: kern netatalk netinet rpc
rwatson at FreeBSD.org
Wed Jun 3 10:46:40 UTC 2009
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
- 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
University of Cambridge
More information about the svn-src-all