From owner-svn-src-all@FreeBSD.ORG Wed Jun 3 10:46:39 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB083106566B; Wed, 3 Jun 2009 10:46:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C47418FC13; Wed, 3 Jun 2009 10:46:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6CECB46B39; Wed, 3 Jun 2009 06:46:39 -0400 (EDT) Date: Wed, 3 Jun 2009 11:46:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20090603083622.GA3824@garage.freebsd.pl> Message-ID: References: <200906021826.n52IQHrh024410@svn.freebsd.org> <20090603083622.GA3824@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r193332 - in head/sys: kern netatalk netinet rpc security/mac X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 10:46:40 -0000 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