Re: policy as configuration data

[Stephen Smalley <sds@tycho.nsa.gov>]

On Wed, 2009-05-06 at 11:07 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Tue, 2009-05-05 at 17:03 -0400, Caleb Case wrote:
> >> We've been looking into a couple of improvements to the SELinux
> >> infrastructure. One of the options we are looking at is treating policy
> >> as configuration data. We've found a couple of sticking points though.
> >>
> >> First, removing a set of trusted tools (running in domains only able to
> >> access files of appropriate types) from the policy modification process
> >> makes it more difficult to control the flow of low integrity data into
> >> the policy.
> > 
> > Policy as configuration data does not imply that you have to let users
> > directly modify the config files without using a tool (which is useful
> > for general integrity and transactional behavior, not just security).
> > passwd data is config data, yet you are supposed to edit it via vipw and
> > tools like useradd.
> > 
> 
> How do you define config data? Is the current module store considered config 
> data? I can't think of a definition that doesn't either include every file on 
> the system or exclude things like passwd, shadow, etc.

Yes, the current module store is config data.  Prior discussions of
treating policy as config data vs. as a software package had nothing to
do with whether or not one would use tools to manage it or whether it
would be source or binary.  

> I think from a users perspective config data means they can drop a file 
> somewhere, restart a service and the additional config is active (apply the same 
> to modifying a file).

I don't really see that as a major problem with SELinux at present; I
think the users would be fine with running semodule -i <module> rather
than dropping in a file as long as we can make that a low overhead
operation.

> 
> >> Also, how can we also support policy access control? For example, how do
> >> we determine who changed the policy if multiple people can edit the
> >> policy files? How do we handle simultaneous edits? What about
> >> transactions?
> > 
> > Again, policy as config data doesn't seem to preclude having a tool
> > mediate the changes.
> > 
> 
> If a tool is required then how is it better than what we have now?

I don't believe the requirement to use tools is one of the real
obstacles to using SELinux at present; if anything, admins seemed to
very much like the ability to control SELinux via semodule and semanage
rather than using vi and make.

I do however see binary modules as creating a lot of fragility, and
without truly bringing the benefits they were originally intended to
confer.  That's a separate issue from whether or not one uses a tool to
install a module.

-- 
Stephen Smalley
National Security Agency


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