Re: Another change we would like to make to libselinux

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On 02/21/12 16:49, Daniel J Walsh wrote:
> On 02/21/2012 03:43 PM, Stephen Smalley wrote:
>> On Thu, 2012-02-16 at 09:47 -0500, Daniel J Walsh wrote:
>>> Currently we have lots of apps trying to figure out which policy
>>> is installed on the system,  We have a function 
>>> selinux_binary_policy_path which returns a path like 
>>> '/etc/selinux/targeted/policy'
>>>
>>> Then these apps do stuff like:
>>>
>>> VER=`cat /sys/fs/selinux/policyver` while [ -e
>>> '/etc/selinux/targetd/policy. + $VER' ]; do VER=$VER-1 done
>>>
>>> While we have had /sys/fs/selinux/policy for a while now.
>>>
>>> I wanted to add an interface to return this path, but I was
>>> trying to figure out a name selinux_loaded_policy_path for
>>> example, but as Eric pointed out to me,
>>> selinux_binary_policy_path is what most users would expect to
>>> return this.  If you look at the man page it even suggest this.
>>>
>>> man selinux_binary_policy_path ... selinux_binary_policy_path() -
>>> binary policy file loaded into kernel
>>>
>>>
>>> Currently the users of this function are the libselinux package, 
>>> setools and policycorutils (sepolgen-ifgen).
>>>
>>>
>>> I am torn between adding stealing this function to return the 
>>> /sys/fs/selinux/policy and then adding
>>> selinux_installed_policy_path for the original function, then
>>> updating the effected packages.
>>>
>>> The problem with this is we would have different behaviour
>>> between older versions of the library. The other options would be
>>> to come up with a better name for the new function and fix the
>>> man pages.
>>>
>>> Suggestions welcomed.
> 
>> Most applications should not be using /sys/fs/selinux/policy, as
>> that requires the kernel to generate the policy image from its
>> in-core data structures and is expensive.  So you certainly should
>> not change selinux_binary_policy_path() to return that pathname.
>> That also would be an incompatible interface change due to the
>> version suffix, as you note.
> 
>> So I think you need a new interface.  selinux_kernel_policy_path()
>> or selinux_active_policy_path() or selinux_loaded_policy_path()
>> seem fine to me.
> 
> 
> Right now we added selinux_current_policy_path and we are using it as
> the default for seinfo, audit2allow, sepolgen-ifgen

So why is it so critical that the in-kernel policy is used for any of these tools?  I can see that for certain high assurance systems that, for example, want to measure policy integrity, would want this, but for 99.9% of the users, its unnecessary.  Its just extra overhead, when the policy is already on disk.  I think it should be an option to use the kernel policy interface, but not the default.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.