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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
