policy as configuration data

policy as configuration data

[Caleb Case]

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.

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?

It's unclear if this is important since part of the goal here is to
simplify and improve the SELinux experience.

Using a trusted set to tools has its advantages and doesn't necessarily
preclude the use of a text based policy. A tool that could give the user
a text module back for modification and accept a text module as input
may be sufficient but doesn't exactly fit into how configuration data
typically works.

We are looking for input on whether having an uncontrolled conf.d style
policy directory that is admin-modifiable without the need for tools is
a high priority for people or if the disadvantages outweigh the desire
to edit files directly.

Questions/comments/rants/flames welcome.

Caleb


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

Re: policy as configuration data

[Stephen Smalley]

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.

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

> It's unclear if this is important since part of the goal here is to
> simplify and improve the SELinux experience.
> 
> Using a trusted set to tools has its advantages and doesn't necessarily
> preclude the use of a text based policy. A tool that could give the user
> a text module back for modification and accept a text module as input
> may be sufficient but doesn't exactly fit into how configuration data
> typically works.
> 
> We are looking for input on whether having an uncontrolled conf.d style
> policy directory that is admin-modifiable without the need for tools is
> a high priority for people or if the disadvantages outweigh the desire
> to edit files directly.
> 
> Questions/comments/rants/flames welcome.
> 
> Caleb
> 
> 
> --
> 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.
-- 
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.

Re: policy as configuration data

[Joshua Brindle]

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.

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


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

>> It's unclear if this is important since part of the goal here is to
>> simplify and improve the SELinux experience.
>>
>> Using a trusted set to tools has its advantages and doesn't necessarily
>> preclude the use of a text based policy. A tool that could give the user
>> a text module back for modification and accept a text module as input
>> may be sufficient but doesn't exactly fit into how configuration data
>> typically works.
>>
>> We are looking for input on whether having an uncontrolled conf.d style
>> policy directory that is admin-modifiable without the need for tools is
>> a high priority for people or if the disadvantages outweigh the desire
>> to edit files directly.
>>
>> Questions/comments/rants/flames welcome.
>>
>> Caleb
>>
>>
>> --
>> 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.


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

Re: policy as configuration data

[Daniel J Walsh]

On 05/06/2009 11:07 AM, 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.
>
> 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).
>
>
>>> 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?
>
Well at least humans could read the policy.
>>> It's unclear if this is important since part of the goal here is to
>>> simplify and improve the SELinux experience.
>>>
>>> Using a trusted set to tools has its advantages and doesn't necessarily
>>> preclude the use of a text based policy. A tool that could give the user
>>> a text module back for modification and accept a text module as input
>>> may be sufficient but doesn't exactly fit into how configuration data
>>> typically works.
>>>
>>> We are looking for input on whether having an uncontrolled conf.d style
>>> policy directory that is admin-modifiable without the need for tools is
>>> a high priority for people or if the disadvantages outweigh the desire
>>> to edit files directly.
>>>
>>> Questions/comments/rants/flames welcome.
>>>
>>> Caleb
>>>
>>>
>>> --
>>> 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.
>
>
> --
> 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.


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

Re: policy as configuration data

[Stephen Smalley]

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.