Re: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Joshua Brindle <method@manicmethod.com>]

Ryan Bradetich wrote:
> On 3/27/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> Ok, so what I'm hearing is that we don't need to preserve support for
>> local boolean and user definitions apart from managed policy.  If anyone
>> disagrees, speak up please.
> 
> Please excuse my ignorance, but I do not have a good handle on the
> terms "local boolean" and "user definitions".
> 
> My guess at what you are referring to better encapsulation of booleans
> into the policy modules.  For example:
> 
> The squid_connect_any boolean/tunable is always present in the policy.
> It is not dependent upon if I had disabled squid support in the
> policy.conf file.  One of the advancements I thought was occurring was
> to better encapsulate boolean support into policy modules.  So the
> squid_connect_any boolean/tunable would only be present if the squid
> module was compiled in or as a loaded module.
> 
> I personally like this idea, because it gives me less to review,
> audit, test, and document  before system deployment.  I am not sure if
> this encapsulation idea is what you are referring to as a "local
> boolean", but I can also live without this support.  As Chris
> mentioned, I would just modify the policy to remove all the booleans
> that are not relevant to my system before deployment.
> 
> Is this the support you are looking to remove?  Or do you mean something 
> else?
> 

Something else. What you mentioned is a policy issue and the discussion 
is about the toolchain/libraries. The local boolean support was added 
before modular policy was added that lets users set boolean values 
persistently locally and init/load_policy (through libselinux) read a 
flat text file with the boolean values and set them in the in-memory 
policydb before loading it into the kernel.

Modular policy has removed the need to modify policies at load time by 
rebuilding the binary from the modules and all local settings (users, 
ports, nodes, booleans, etc). We sought to remove the in-memory 
modification to policies so that we could analyze the actual policy 
binary being used on the system and not something that would be modified 
before being loaded. It also allowed us to add more flexibility by way 
of semanage that was not there previously.


--
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.