[RFC] 0/4 - Hierarchal apache policy for reference policy

[RFC] 0/4 - Hierarchal apache policy for reference policy

[Joshua Brindle]

This is an RFC for policy allowing management delegation through 
hierarchical types.

Policy management often is handled by different administrators, based on 
the application or applications that are being governed. As a result, 
providing a means to delegate access to manage only certain aspects of 
policy is desirable, and can be accomplished using hierarchical types.

The proof of concept apache policy module illustrates policy management 
delegation through hierarchical types. This example apache policy works 
together with an adds metapolicy to the apache module and adds a policy 
server labeling file (apache.pc) that must be appended to the policy 
context file (the default for policy server is 
/etc/selinux/policy_contexts) to split apache’s policy management 
between different users.

In this policy, for example, management access to apache content is 
broken down hierarchically based on the content owner. Then 
apache_t.user_content is labeled user_apache_policy_t to only allow 
user_t to add new rules for apache_t.user_content type. Similar rules 
prevent user_t from using types like apache_t.staff_content. See the end 
of apache_per_role_template() in apache.if for the rules that govern how 
users change policy.

The enforcement of the metapolicy requires the policy management server, 
which will be released for preview soon.



--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Karl MacMillan]

Joshua Brindle wrote:
> This is an RFC for policy allowing management delegation through 
> hierarchical types.
> 
> Policy management often is handled by different administrators, based on 
> the application or applications that are being governed. As a result, 
> providing a means to delegate access to manage only certain aspects of 
> policy is desirable, and can be accomplished using hierarchical types.
> 
> The proof of concept apache policy module illustrates policy management 
> delegation through hierarchical types. This example apache policy works 
> together with an adds metapolicy to the apache module

It's good to see progress on this and a real fleshed-out example. I look 
forward to seeing the prototype policy server.

I think the biggest hurdle to this gaining widespread use is the length 
of the meta-policy, especially since it essentially repeats the policy 
for the sub-types. Any ideas about how to shorten this policy?

The other large issue, of course, is that this demonstrates how invasive 
the policy changes are in order to support delegation. This makes it 
very difficult for a policy admin to create a separate policy module 
that a) places hierarchical restrictions on a set of types and b) 
delegates administrative privileges to an admin type to make changes to 
those types.

My guess is that for real administrative roles to become viable in 
SELinux they are going to be largely site-defined in loadable modules 
(and the work at RH along those lines is using that as a starting 
assumption). So some way to support that seems necessary. At the very 
least I think that decoupling the hierarchical restrictions from the 
identifier names is needed. This also makes hierarchy work better with 
reference policy scoping.

Karl



--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Joshua Brindle]

Karl MacMillan wrote:
> Joshua Brindle wrote:
>> This is an RFC for policy allowing management delegation through 
>> hierarchical types.
>>
>> Policy management often is handled by different administrators, based 
>> on the application or applications that are being governed. As a 
>> result, providing a means to delegate access to manage only certain 
>> aspects of policy is desirable, and can be accomplished using 
>> hierarchical types.
>>
>> The proof of concept apache policy module illustrates policy 
>> management delegation through hierarchical types. This example apache 
>> policy works together with an adds metapolicy to the apache module
> 
> It's good to see progress on this and a real fleshed-out example. I look 
> forward to seeing the prototype policy server.
> 
> I think the biggest hurdle to this gaining widespread use is the length 
> of the meta-policy, especially since it essentially repeats the policy 
> for the sub-types. Any ideas about how to shorten this policy?
> 

nit: the meta-policy is short (5 lines). The policy itself is longer due 
to the propagation of rules to children types.

> The other large issue, of course, is that this demonstrates how invasive 
> the policy changes are in order to support delegation. This makes it 
> very difficult for a policy admin to create a separate policy module 
> that a) places hierarchical restrictions on a set of types and b) 
> delegates administrative privileges to an admin type to make changes to 
> those types.
> 

I'm not sure how desirable ad-hoc delegation is. Just like normal policy 
meta policy needs to be well thought out in order to meet specific 
security goals (and do so without allowing bypass, etc).

> My guess is that for real administrative roles to become viable in 
> SELinux they are going to be largely site-defined in loadable modules 
> (and the work at RH along those lines is using that as a starting 
> assumption). So some way to support that seems necessary. At the very 
> least I think that decoupling the hierarchical restrictions from the 
> identifier names is needed. This also makes hierarchy work better with 
> reference policy scoping.
> 

I don't know if I believe this, all of our experience with making 
administrative roles is that it is difficult, we know, for example, that 
the secadm and sysadm roles are hardly separate and there are trivial 
bypasses that the sysadm role can use to gain secadm type access.

Decoupling the hierarchy from the identifier seems like it would make 
understanding the hierarchy and the resulting metapolicy very difficult.

I'm open to debate though, that is the purpose of sending this up at 
this time.


--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Karl MacMillan]

Joshua Brindle wrote:
> Karl MacMillan wrote:
>> Joshua Brindle wrote:
>>> This is an RFC for policy allowing management delegation through 
>>> hierarchical types.
>>>
>>> Policy management often is handled by different administrators, based 
>>> on the application or applications that are being governed. As a 
>>> result, providing a means to delegate access to manage only certain 
>>> aspects of policy is desirable, and can be accomplished using 
>>> hierarchical types.
>>>
>>> The proof of concept apache policy module illustrates policy 
>>> management delegation through hierarchical types. This example apache 
>>> policy works together with an adds metapolicy to the apache module
>>
>> It's good to see progress on this and a real fleshed-out example. I 
>> look forward to seeing the prototype policy server.
>>
>> I think the biggest hurdle to this gaining widespread use is the 
>> length of the meta-policy, especially since it essentially repeats the 
>> policy for the sub-types. Any ideas about how to shorten this policy?
>>
> 
> nit: the meta-policy is short (5 lines). The policy itself is longer due 
> to the propagation of rules to children types.
> 

Fine - but that answer the question. Having to define container types 
with a superset of the rules results in a much longer policy. I think 
that it is going to be hard to convince people to add that policy.

>> The other large issue, of course, is that this demonstrates how 
>> invasive the policy changes are in order to support delegation. This 
>> makes it very difficult for a policy admin to create a separate policy 
>> module that a) places hierarchical restrictions on a set of types and 
>> b) delegates administrative privileges to an admin type to make 
>> changes to those types.
>>
> 
> I'm not sure how desirable ad-hoc delegation is.

It is not ad-hoc, it is just not done by the distribution or upstream.

  Just like normal policy
> meta policy needs to be well thought out in order to meet specific 
> security goals (and do so without allowing bypass, etc).
> 

Sure, but that doesn't mean that an administrator can't do this. The 
upstream refpolicy and / or distributions cannot meet all of the users 
needs - I'm just suggesting that we make it possible for people to do 
customization. It is their responsibility to do a good job at that point.

The alternative (take what is given or leave it) is not very attractive 
if it doesn't meet your needs.

>> My guess is that for real administrative roles to become viable in 
>> SELinux they are going to be largely site-defined in loadable modules 
>> (and the work at RH along those lines is using that as a starting 
>> assumption). So some way to support that seems necessary. At the very 
>> least I think that decoupling the hierarchical restrictions from the 
>> identifier names is needed. This also makes hierarchy work better with 
>> reference policy scoping.
>>
> 
> I don't know if I believe this, all of our experience with making 
> administrative roles is that it is difficult, we know, for example, that 
> the secadm and sysadm roles are hardly separate and there are trivial 
> bypasses that the sysadm role can use to gain secadm type access.
> 

I don't think that secadm and sysadm are representative because they 
both end up touching files / processes that could potentially allow 
bypass. Allowing an admin to only run adduser or write to web pages is 
much simpler.

Just because it is hard doesn't mean that it shouldn't be possible to be 
done by admins.

Also, this customization might be done with tools that help them get it 
right. In that case, the customization still to land in a module.

> Decoupling the hierarchy from the identifier seems like it would make 
> understanding the hierarchy and the resulting metapolicy very difficult.
> 

I'm not certain that determining the hierarchy tree is the limiting 
factor in terms of understandability.

Much more important to me is that it means that customization will 
almost always require changes to the original policy. I just don't think 
that is supportable.

Karl


--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Stephen Smalley]

On Thu, 2007-01-18 at 13:40 -0500, Karl MacMillan wrote:
> Joshua Brindle wrote:
> > Karl MacMillan wrote:
> >> Joshua Brindle wrote:
> >>> This is an RFC for policy allowing management delegation through 
> >>> hierarchical types.
> >>>
> >>> Policy management often is handled by different administrators, based 
> >>> on the application or applications that are being governed. As a 
> >>> result, providing a means to delegate access to manage only certain 
> >>> aspects of policy is desirable, and can be accomplished using 
> >>> hierarchical types.
> >>>
> >>> The proof of concept apache policy module illustrates policy 
> >>> management delegation through hierarchical types. This example apache 
> >>> policy works together with an adds metapolicy to the apache module
> >>
> >> It's good to see progress on this and a real fleshed-out example. I 
> >> look forward to seeing the prototype policy server.
> >>
> >> I think the biggest hurdle to this gaining widespread use is the 
> >> length of the meta-policy, especially since it essentially repeats the 
> >> policy for the sub-types. Any ideas about how to shorten this policy?
> >>
> > 
> > nit: the meta-policy is short (5 lines). The policy itself is longer due 
> > to the propagation of rules to children types.
> > 
> 
> Fine - but that answer the question. Having to define container types 
> with a superset of the rules results in a much longer policy. I think 
> that it is going to be hard to convince people to add that policy.

Policy build could automatically generate the rules for the container
types from the child type rules, as long as they come from the same
source (e.g. all part of the base policy build, or all within the same
module).  Then you only need to explicitly state rules for the container
types for accesses that you wish to permit to externally defined
children.

> >> The other large issue, of course, is that this demonstrates how 
> >> invasive the policy changes are in order to support delegation. This 
> >> makes it very difficult for a policy admin to create a separate policy 
> >> module that a) places hierarchical restrictions on a set of types and 
> >> b) delegates administrative privileges to an admin type to make 
> >> changes to those types.
> >>
> > 
> > I'm not sure how desirable ad-hoc delegation is.
> 
> It is not ad-hoc, it is just not done by the distribution or upstream.
> 
>   Just like normal policy
> > meta policy needs to be well thought out in order to meet specific 
> > security goals (and do so without allowing bypass, etc).
> > 
> 
> Sure, but that doesn't mean that an administrator can't do this. The 
> upstream refpolicy and / or distributions cannot meet all of the users 
> needs - I'm just suggesting that we make it possible for people to do 
> customization. It is their responsibility to do a good job at that point.
> 
> The alternative (take what is given or leave it) is not very attractive 
> if it doesn't meet your needs.

Agreed; we need to leave the choice in the user's hands, and just
provide them with good tooling for making informed choices.  We can't
predict all the different ways in which real admins will want to
delegate.

> >> My guess is that for real administrative roles to become viable in 
> >> SELinux they are going to be largely site-defined in loadable modules 
> >> (and the work at RH along those lines is using that as a starting 
> >> assumption). So some way to support that seems necessary. At the very 
> >> least I think that decoupling the hierarchical restrictions from the 
> >> identifier names is needed. This also makes hierarchy work better with 
> >> reference policy scoping.
> >>
> > 
> > I don't know if I believe this, all of our experience with making 
> > administrative roles is that it is difficult, we know, for example, that 
> > the secadm and sysadm roles are hardly separate and there are trivial 
> > bypasses that the sysadm role can use to gain secadm type access.
> > 
> 
> I don't think that secadm and sysadm are representative because they 
> both end up touching files / processes that could potentially allow 
> bypass. Allowing an admin to only run adduser or write to web pages is 
> much simpler.
> 
> Just because it is hard doesn't mean that it shouldn't be possible to be 
> done by admins.

Agreed.

> > Decoupling the hierarchy from the identifier seems like it would make 
> > understanding the hierarchy and the resulting metapolicy very difficult.
> > 
> 
> I'm not certain that determining the hierarchy tree is the limiting 
> factor in terms of understandability.

Particularly with appropriate tooling to make the tree visible.

> Much more important to me is that it means that customization will 
> almost always require changes to the original policy. I just don't think 
> that is supportable.

Yes, that is presently a real obstacle to e.g. implementing roles at a
site.

-- 
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Karl MacMillan]

Stephen Smalley wrote:
> On Thu, 2007-01-18 at 13:40 -0500, Karl MacMillan wrote:
>> Joshua Brindle wrote:
>>> Karl MacMillan wrote:
>>>> Joshua Brindle wrote:

<snip>

>>>> I think the biggest hurdle to this gaining widespread use is the 
>>>> length of the meta-policy, especially since it essentially repeats the 
>>>> policy for the sub-types. Any ideas about how to shorten this policy?
>>>>
>>> nit: the meta-policy is short (5 lines). The policy itself is longer due 
>>> to the propagation of rules to children types.
>>>
>> Fine - but that answer the question. Having to define container types 
>> with a superset of the rules results in a much longer policy. I think 
>> that it is going to be hard to convince people to add that policy.
> 
> Policy build could automatically generate the rules for the container
> types from the child type rules, as long as they come from the same
> source (e.g. all part of the base policy build, or all within the same
> module).  Then you only need to explicitly state rules for the container
> types for accesses that you wish to permit to externally defined
> children.
> 

That's probably a good solution. Wouldn't be too hard to make a tool to 
do this from selgen / sepolgen / madison.

Karl

--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> Stephen Smalley wrote:
> > On Thu, 2007-01-18 at 13:40 -0500, Karl MacMillan wrote:
> >> Joshua Brindle wrote:
> >>> Karl MacMillan wrote:
> >>>> Joshua Brindle wrote:
> 
> <snip>
> 
> >>>> I think the biggest hurdle to this gaining widespread use is the 
> >>>> length of the meta-policy, especially since it 
> essentially repeats 
> >>>> the policy for the sub-types. Any ideas about how to 
> shorten this policy?
> >>>>
> >>> nit: the meta-policy is short (5 lines). The policy 
> itself is longer 
> >>> due to the propagation of rules to children types.
> >>>
> >> Fine - but that answer the question. Having to define 
> container types 
> >> with a superset of the rules results in a much longer 
> policy. I think 
> >> that it is going to be hard to convince people to add that policy.
> > 
> > Policy build could automatically generate the rules for the 
> container 
> > types from the child type rules, as long as they come from the same 
> > source (e.g. all part of the base policy build, or all 
> within the same 
> > module).  Then you only need to explicitly state rules for the 
> > container types for accesses that you wish to permit to externally 
> > defined children.
> > 
> 
> That's probably a good solution. Wouldn't be too hard to make 
> a tool to do this from selgen / sepolgen / madison.


This defeats the purpose of the hierarchy. The container types define
the maximum permissions that can be granted to a child. The intention is
for the security admin to create types with the permissions acceptable
to meet his goals, and allow other admins to securely make finer grained
children types. 

The proposed solution gives the opposite effect, it builds container
types from children so the children must meet the requirements of the
parent types without knowing them.


--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Stephen Smalley]

On Thu, 2007-01-18 at 15:00 -0500, Joshua Brindle wrote:
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> > 
> > Stephen Smalley wrote:
> > > On Thu, 2007-01-18 at 13:40 -0500, Karl MacMillan wrote:
> > >> Joshua Brindle wrote:
> > >>> Karl MacMillan wrote:
> > >>>> Joshua Brindle wrote:
> > 
> > <snip>
> > 
> > >>>> I think the biggest hurdle to this gaining widespread use is the 
> > >>>> length of the meta-policy, especially since it 
> > essentially repeats 
> > >>>> the policy for the sub-types. Any ideas about how to 
> > shorten this policy?
> > >>>>
> > >>> nit: the meta-policy is short (5 lines). The policy 
> > itself is longer 
> > >>> due to the propagation of rules to children types.
> > >>>
> > >> Fine - but that answer the question. Having to define 
> > container types 
> > >> with a superset of the rules results in a much longer 
> > policy. I think 
> > >> that it is going to be hard to convince people to add that policy.
> > > 
> > > Policy build could automatically generate the rules for the 
> > container 
> > > types from the child type rules, as long as they come from the same 
> > > source (e.g. all part of the base policy build, or all 
> > within the same 
> > > module).  Then you only need to explicitly state rules for the 
> > > container types for accesses that you wish to permit to externally 
> > > defined children.
> > > 
> > 
> > That's probably a good solution. Wouldn't be too hard to make 
> > a tool to do this from selgen / sepolgen / madison.
> 
> 
> This defeats the purpose of the hierarchy. The container types define
> the maximum permissions that can be granted to a child. The intention is
> for the security admin to create types with the permissions acceptable
> to meet his goals, and allow other admins to securely make finer grained
> children types. 
> 
> The proposed solution gives the opposite effect, it builds container
> types from children so the children must meet the requirements of the
> parent types without knowing them.

No, notice that I only said that one would automatically propagate
accesses from the children to the parent if they come from the same
source (base policy build or within the same module).  You wouldn't
automatically propagate beyond that scope, so if a type in a module is a
child of a parent type in the base (or any other previously added
module), it would still be constrained to whatever was explicitly
specified by the base (or other module) on the parent type.  It merely
avoids the need to duplicate specification within the base policy or
within a single module when both the parent and the child types are
defined within that base or 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.

RE: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Stephen Smalley]

On Thu, 2007-01-18 at 15:24 -0500, Stephen Smalley wrote:
> On Thu, 2007-01-18 at 15:00 -0500, Joshua Brindle wrote:
> > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> > > 
> > > Stephen Smalley wrote:
> > > > On Thu, 2007-01-18 at 13:40 -0500, Karl MacMillan wrote:
> > > >> Joshua Brindle wrote:
> > > >>> Karl MacMillan wrote:
> > > >>>> Joshua Brindle wrote:
> > > 
> > > <snip>
> > > 
> > > >>>> I think the biggest hurdle to this gaining widespread use is the 
> > > >>>> length of the meta-policy, especially since it 
> > > essentially repeats 
> > > >>>> the policy for the sub-types. Any ideas about how to 
> > > shorten this policy?
> > > >>>>
> > > >>> nit: the meta-policy is short (5 lines). The policy 
> > > itself is longer 
> > > >>> due to the propagation of rules to children types.
> > > >>>
> > > >> Fine - but that answer the question. Having to define 
> > > container types 
> > > >> with a superset of the rules results in a much longer 
> > > policy. I think 
> > > >> that it is going to be hard to convince people to add that policy.
> > > > 
> > > > Policy build could automatically generate the rules for the 
> > > container 
> > > > types from the child type rules, as long as they come from the same 
> > > > source (e.g. all part of the base policy build, or all 
> > > within the same 
> > > > module).  Then you only need to explicitly state rules for the 
> > > > container types for accesses that you wish to permit to externally 
> > > > defined children.
> > > > 
> > > 
> > > That's probably a good solution. Wouldn't be too hard to make 
> > > a tool to do this from selgen / sepolgen / madison.
> > 
> > 
> > This defeats the purpose of the hierarchy. The container types define
> > the maximum permissions that can be granted to a child. The intention is
> > for the security admin to create types with the permissions acceptable
> > to meet his goals, and allow other admins to securely make finer grained
> > children types. 
> > 
> > The proposed solution gives the opposite effect, it builds container
> > types from children so the children must meet the requirements of the
> > parent types without knowing them.
> 
> No, notice that I only said that one would automatically propagate
> accesses from the children to the parent if they come from the same
> source (base policy build or within the same module).  You wouldn't
> automatically propagate beyond that scope, so if a type in a module is a
> child of a parent type in the base (or any other previously added
> module), it would still be constrained to whatever was explicitly
> specified by the base (or other module) on the parent type.  It merely
> avoids the need to duplicate specification within the base policy or
> within a single module when both the parent and the child types are
> defined within that base or module.

Note btw that the value of such automatic propagation may be minimal for
a highly modularized, highly parameterized policy (ala apache).
 
-- 
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Joshua Brindle]

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> On Thu, 2007-01-18 at 15:00 -0500, Joshua Brindle wrote:
> > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
> > > 
> > > Stephen Smalley wrote:
> > > > On Thu, 2007-01-18 at 13:40 -0500, Karl MacMillan wrote:
> > > >> Joshua Brindle wrote:
> > > >>> Karl MacMillan wrote:
> > > >>>> Joshua Brindle wrote:
> > > 
> > > <snip>
> > > 
> > > >>>> I think the biggest hurdle to this gaining widespread use is 
> > > >>>> the length of the meta-policy, especially since it
> > > essentially repeats
> > > >>>> the policy for the sub-types. Any ideas about how to
> > > shorten this policy?
> > > >>>>
> > > >>> nit: the meta-policy is short (5 lines). The policy
> > > itself is longer
> > > >>> due to the propagation of rules to children types.
> > > >>>
> > > >> Fine - but that answer the question. Having to define
> > > container types
> > > >> with a superset of the rules results in a much longer
> > > policy. I think
> > > >> that it is going to be hard to convince people to add 
> that policy.
> > > > 
> > > > Policy build could automatically generate the rules for the
> > > container
> > > > types from the child type rules, as long as they come from the 
> > > > same source (e.g. all part of the base policy build, or all
> > > within the same
> > > > module).  Then you only need to explicitly state rules for the 
> > > > container types for accesses that you wish to permit to 
> externally 
> > > > defined children.
> > > > 
> > > 
> > > That's probably a good solution. Wouldn't be too hard to 
> make a tool 
> > > to do this from selgen / sepolgen / madison.
> > 
> > 
> > This defeats the purpose of the hierarchy. The container 
> types define 
> > the maximum permissions that can be granted to a child. The 
> intention 
> > is for the security admin to create types with the permissions 
> > acceptable to meet his goals, and allow other admins to 
> securely make 
> > finer grained children types.
> > 
> > The proposed solution gives the opposite effect, it builds 
> container 
> > types from children so the children must meet the 
> requirements of the 
> > parent types without knowing them.
> 
> No, notice that I only said that one would automatically 
> propagate accesses from the children to the parent if they 
> come from the same source (base policy build or within the 
> same module).  You wouldn't automatically propagate beyond 
> that scope, so if a type in a module is a child of a parent 
> type in the base (or any other previously added module), it 
> would still be constrained to whatever was explicitly 
> specified by the base (or other module) on the parent type.  
> It merely avoids the need to duplicate specification within 
> the base policy or within a single module when both the 
> parent and the child types are defined within that base or module.
> 

This implies that policy won't be added by updating pre-existing modules
to add access and would only be added via extra modules. 

So the result would be that someone adding permissions to a child type
in a pre-existing module would be an insertion failure because they
weren't allowed to add permissions to the parent rather than a hierarchy
violation error.

If one added the same rule to another module they'd get a hierarchy
violation error, however. So the user would experience different errors
depending on how they added the rule to the policy.


--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Karl MacMillan]

Joshua Brindle wrote:
>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
>>
>> On Thu, 2007-01-18 at 15:00 -0500, Joshua Brindle wrote:

<snip>

>>> The proposed solution gives the opposite effect, it builds 
>> container 
>>> types from children so the children must meet the 
>> requirements of the 
>>> parent types without knowing them.
>> No, notice that I only said that one would automatically 
>> propagate accesses from the children to the parent if they 
>> come from the same source (base policy build or within the 
>> same module).  You wouldn't automatically propagate beyond 
>> that scope, so if a type in a module is a child of a parent 
>> type in the base (or any other previously added module), it 
>> would still be constrained to whatever was explicitly 
>> specified by the base (or other module) on the parent type.  
>> It merely avoids the need to duplicate specification within 
>> the base policy or within a single module when both the 
>> parent and the child types are defined within that base or module.
>>
> 
> This implies that policy won't be added by updating pre-existing modules
> to add access and would only be added via extra modules. 
> 
> So the result would be that someone adding permissions to a child type
> in a pre-existing module would be an insertion failure because they
> weren't allowed to add permissions to the parent rather than a hierarchy
> violation error.
> 
> If one added the same rule to another module they'd get a hierarchy
> violation error, however. So the user would experience different errors
> depending on how they added the rule to the policy.

I don't follow - I thought that the typing meant that it didn't matter 
where the rule came from, only what the source and destination types 
were. If you added additional rules via the module, the target types 
should have the same type as they do in the original module.

Karl


--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> Joshua Brindle wrote:
> >> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> >>
> >> On Thu, 2007-01-18 at 15:00 -0500, Joshua Brindle wrote:
> 
> <snip>
> 
> >>> The proposed solution gives the opposite effect, it builds
> >> container
> >>> types from children so the children must meet the
> >> requirements of the
> >>> parent types without knowing them.
> >> No, notice that I only said that one would automatically propagate 
> >> accesses from the children to the parent if they come from 
> the same 
> >> source (base policy build or within the same module).  You 
> wouldn't 
> >> automatically propagate beyond that scope, so if a type in 
> a module 
> >> is a child of a parent type in the base (or any other previously 
> >> added module), it would still be constrained to whatever was 
> >> explicitly specified by the base (or other module) on the parent 
> >> type.
> >> It merely avoids the need to duplicate specification 
> within the base 
> >> policy or within a single module when both the parent and 
> the child 
> >> types are defined within that base or module.
> >>
> > 
> > This implies that policy won't be added by updating pre-existing 
> > modules to add access and would only be added via extra modules.
> > 
> > So the result would be that someone adding permissions to a 
> child type 
> > in a pre-existing module would be an insertion failure because they 
> > weren't allowed to add permissions to the parent rather than a 
> > hierarchy violation error.
> > 
> > If one added the same rule to another module they'd get a hierarchy 
> > violation error, however. So the user would experience different 
> > errors depending on how they added the rule to the policy.
> 
> I don't follow - I thought that the typing meant that it 
> didn't matter where the rule came from, only what the source 
> and destination types were. If you added additional rules via 
> the module, the target types should have the same type as 
> they do in the original module.
> 

What I was saying was how it would behave differently if you generated
rules for all the parents of a child at build time within a single
module. If you automatically did that then adding a rule to a child
would get propagated to the parent which would result in an access
violation at insert time. If you added the rule from another module it
would show up as a hierarchy violation instead.


--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Karl MacMillan]

Joshua Brindle wrote:
>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
>>
>> Joshua Brindle wrote:
>>> If one added the same rule to another module they'd get a hierarchy 
>>> violation error, however. So the user would experience different 
>>> errors depending on how they added the rule to the policy.
>> I don't follow - I thought that the typing meant that it 
>> didn't matter where the rule came from, only what the source 
>> and destination types were. If you added additional rules via 
>> the module, the target types should have the same type as 
>> they do in the original module.
>>
> 
> What I was saying was how it would behave differently if you generated
> rules for all the parents of a child at build time within a single
> module. If you automatically did that then adding a rule to a child
> would get propagated to the parent which would result in an access
> violation at insert time. If you added the rule from another module it
> would show up as a hierarchy violation instead.

Ah - I see what you are saying. I was assuming that this would be a 
development tool manually invoked to aid policy developers. Not 
something that would always happen as part of the build.

Also, I assume that for the most part the container types will be given 
very broad privileges rather than the fine-grained approach taken with 
the apache policy. Otherwise chances are that most updates will fail 
from hierarchy violations because you forgot one small access. In other 
words, the closer the container type policy to the subtypes the less 
useful it actually is (because you would just not delegate access to 
someone else to update it).

Karl

--
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: [RFC] 0/4 - Hierarchal apache policy for reference policy

[Daniel J Walsh]

So how does this work.  I just added the following policy to create a 
httpd_squid_script_exec_t.

policy_module(squid_cgi,1.0.0)

apache_content_template(squid)
corenet_tcp_connect_http_cache_port(httpd_squid_script_t)
squid_read_config(httpd_squid_script_t)
allow httpd_squid_script_t self:tcp_socket create_socket_perms;
sysnet_read_config(httpd_squid_script_t)
corenet_non_ipsec_sendrecv(httpd_squid_script_t)

I take it the base apache policy did not have the right to read squid 
config data.



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