[refpolicy] [RFC] drop nodecons

[refpolicy] [RFC] drop nodecons

[Christopher J. PeBenito]

Some time ago we dropped the netifcons (and related types) from
refpolicy, since all networking domains had access to all interfaces.
This made it difficult for users to label an interface with a new type
and have only their custom domain be allowed access to that interface.
So we dropped the netifcons and changed the policy for networking
domains to use "generic" netif_t interfaces.

I believe we should also do this with the nodecons.  The main issue is
with MLS policy users.  Some of the current nodecons specify system low,
but the default sensitivity (initial sid) for a node is system
low-system high.  If we remove these system low nodecons, then they
would revert to system low-system high.  If we use the full
network_node() macros only in the MLS policy, the MLS policy will be
broken since domains will only be allowed generic node access (node_t).
We could use raw netifcons and label the nodes in question as node_t at
system low, but this could cause problems if the user also wants to
change the type of the node.  Thoughts?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [RFC] drop nodecons

[Paul Moore]

On Wednesday 07 January 2009 10:25:13 am Christopher J. PeBenito wrote:
> Some time ago we dropped the netifcons (and related types) from
> refpolicy, since all networking domains had access to all interfaces.
> This made it difficult for users to label an interface with a new
> type and have only their custom domain be allowed access to that
> interface. So we dropped the netifcons and changed the policy for
> networking domains to use "generic" netif_t interfaces.
>
> I believe we should also do this with the nodecons.  The main issue
> is with MLS policy users.  Some of the current nodecons specify
> system low, but the default sensitivity (initial sid) for a node is
> system low-system high.  If we remove these system low nodecons, then
> they would revert to system low-system high.  If we use the full
> network_node() macros only in the MLS policy, the MLS policy will be
> broken since domains will only be allowed generic node access
> (node_t). We could use raw netifcons and label the nodes in question
> as node_t at system low, but this could cause problems if the user
> also wants to change the type of the node.  Thoughts?

>From your first paragraph it sounds like this is a solved problem for 
netifcons, even in the MLS case.  Why can't the same approach be used 
for netnodecons?  Is it the special MLS cases where nodes are labeled 
with system low?  If so, why would the change from system low-system 
high break things since the effective MLS label is still system low?

I agree this is a good idea, I just don't understand the issue well 
enough to see the problem.

-- 
paul moore
linux @ hp

[refpolicy] [RFC] drop nodecons

[Christopher J. PeBenito]

On Wed, 2009-01-07 at 14:21 -0500, Paul Moore wrote:
> On Wednesday 07 January 2009 10:25:13 am Christopher J. PeBenito wrote:
> > Some time ago we dropped the netifcons (and related types) from
> > refpolicy, since all networking domains had access to all interfaces.
> > This made it difficult for users to label an interface with a new
> > type and have only their custom domain be allowed access to that
> > interface. So we dropped the netifcons and changed the policy for
> > networking domains to use "generic" netif_t interfaces.
> >
> > I believe we should also do this with the nodecons.  The main issue
> > is with MLS policy users.  Some of the current nodecons specify
> > system low, but the default sensitivity (initial sid) for a node is
> > system low-system high.  If we remove these system low nodecons, then
> > they would revert to system low-system high.  If we use the full
> > network_node() macros only in the MLS policy, the MLS policy will be
> > broken since domains will only be allowed generic node access
> > (node_t). We could use raw netifcons and label the nodes in question
> > as node_t at system low, but this could cause problems if the user
> > also wants to change the type of the node.  Thoughts?
> 
> From your first paragraph it sounds like this is a solved problem for 
> netifcons, even in the MLS case.  Why can't the same approach be used 
> for netnodecons?  Is it the special MLS cases where nodes are labeled 
> with system low?  If so, why would the change from system low-system 
> high break things since the effective MLS label is still system low?
> 
> I agree this is a good idea, I just don't understand the issue well 
> enough to see the problem.

All of the netifs are syslow-syshigh.  So removing netifcons had no MLS
effect, since the netif initial sid is also syslow-syshigh.  The node
case is different, as there would be an MLS effect.  For example,
0.0.0.0/32 is currently syslow.  If we remove the nodecon, 0.0.0.0/32
would become syslow-syshigh since the node initial sid is
syslow-syshigh.

So if we don't care about the MLS effect, then I can just drop the
nodecons, and there isn't an issue.  Since there are nodes that are not
syslow-syshigh, I figured that there might be some concern.

If there is a concern the options are:

1. don't drop the nodecons and related types (eg inaddr_any_node_t)
2. drop the nodecons and related types for non-MLS policies (causes a
mess of ifdef mls_enabled TE issues)
3. drop the related types in all cases, drop the nodecons for non-MLS
policies (you can't modify the type of the nodes defined in the base
module via semanage--at least, I can't get it to work)

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [RFC] drop nodecons

[Paul Moore]

On Wednesday 07 January 2009 3:24:16 pm Christopher J. PeBenito wrote:
> On Wed, 2009-01-07 at 14:21 -0500, Paul Moore wrote:
> > On Wednesday 07 January 2009 10:25:13 am Christopher J. PeBenito 
wrote:
> > > Some time ago we dropped the netifcons (and related types) from
> > > refpolicy, since all networking domains had access to all
> > > interfaces. This made it difficult for users to label an
> > > interface with a new type and have only their custom domain be
> > > allowed access to that interface. So we dropped the netifcons and
> > > changed the policy for networking domains to use "generic"
> > > netif_t interfaces.
> > >
> > > I believe we should also do this with the nodecons.  The main
> > > issue is with MLS policy users.  Some of the current nodecons
> > > specify system low, but the default sensitivity (initial sid) for
> > > a node is system low-system high.  If we remove these system low
> > > nodecons, then they would revert to system low-system high.  If
> > > we use the full network_node() macros only in the MLS policy, the
> > > MLS policy will be broken since domains will only be allowed
> > > generic node access (node_t). We could use raw netifcons and
> > > label the nodes in question as node_t at system low, but this
> > > could cause problems if the user also wants to change the type of
> > > the node.  Thoughts?
> >
> > From your first paragraph it sounds like this is a solved problem
> > for netifcons, even in the MLS case.  Why can't the same approach
> > be used for netnodecons?  Is it the special MLS cases where nodes
> > are labeled with system low?  If so, why would the change from
> > system low-system high break things since the effective MLS label
> > is still system low?
> >
> > I agree this is a good idea, I just don't understand the issue well
> > enough to see the problem.
>
> All of the netifs are syslow-syshigh.  So removing netifcons had no
> MLS effect, since the netif initial sid is also syslow-syshigh.  The
> node case is different, as there would be an MLS effect.  For
> example, 0.0.0.0/32 is currently syslow.  If we remove the nodecon,
> 0.0.0.0/32 would become syslow-syshigh since the node initial sid is
> syslow-syshigh.
>
> So if we don't care about the MLS effect, then I can just drop the
> nodecons, and there isn't an issue.  Since there are nodes that are
> not syslow-syshigh, I figured that there might be some concern.

Thanks for the clarification.  Personally I'm not sure this is a 
significant concern, syslow-syshi seems reasonable to me for the 
default.  Allowing users to customize the node labeling is a big win 
and should offset any problems with the move away from syslo.

The next step is to get semanage to label network nodes (or fix it if it 
is broken).

-- 
paul moore
linux @ hp

[refpolicy] [RFC] drop nodecons

[Stephen Smalley]

On Wed, 2009-01-07 at 17:20 -0500, Paul Moore wrote:
> On Wednesday 07 January 2009 3:24:16 pm Christopher J. PeBenito wrote:
> > On Wed, 2009-01-07 at 14:21 -0500, Paul Moore wrote:
> > > On Wednesday 07 January 2009 10:25:13 am Christopher J. PeBenito 
> wrote:
> > > > Some time ago we dropped the netifcons (and related types) from
> > > > refpolicy, since all networking domains had access to all
> > > > interfaces. This made it difficult for users to label an
> > > > interface with a new type and have only their custom domain be
> > > > allowed access to that interface. So we dropped the netifcons and
> > > > changed the policy for networking domains to use "generic"
> > > > netif_t interfaces.
> > > >
> > > > I believe we should also do this with the nodecons.  The main
> > > > issue is with MLS policy users.  Some of the current nodecons
> > > > specify system low, but the default sensitivity (initial sid) for
> > > > a node is system low-system high.  If we remove these system low
> > > > nodecons, then they would revert to system low-system high.  If
> > > > we use the full network_node() macros only in the MLS policy, the
> > > > MLS policy will be broken since domains will only be allowed
> > > > generic node access (node_t). We could use raw netifcons and
> > > > label the nodes in question as node_t at system low, but this
> > > > could cause problems if the user also wants to change the type of
> > > > the node.  Thoughts?
> > >
> > > From your first paragraph it sounds like this is a solved problem
> > > for netifcons, even in the MLS case.  Why can't the same approach
> > > be used for netnodecons?  Is it the special MLS cases where nodes
> > > are labeled with system low?  If so, why would the change from
> > > system low-system high break things since the effective MLS label
> > > is still system low?
> > >
> > > I agree this is a good idea, I just don't understand the issue well
> > > enough to see the problem.
> >
> > All of the netifs are syslow-syshigh.  So removing netifcons had no
> > MLS effect, since the netif initial sid is also syslow-syshigh.  The
> > node case is different, as there would be an MLS effect.  For
> > example, 0.0.0.0/32 is currently syslow.  If we remove the nodecon,
> > 0.0.0.0/32 would become syslow-syshigh since the node initial sid is
> > syslow-syshigh.
> >
> > So if we don't care about the MLS effect, then I can just drop the
> > nodecons, and there isn't an issue.  Since there are nodes that are
> > not syslow-syshigh, I figured that there might be some concern.
> 
> Thanks for the clarification.  Personally I'm not sure this is a 
> significant concern, syslow-syshi seems reasonable to me for the 
> default.  Allowing users to customize the node labeling is a big win 
> and should offset any problems with the move away from syslo.
> 
> The next step is to get semanage to label network nodes (or fix it if it 
> is broken).

semanage node support exists, but might not correctly handle
conflicting/overlapping definitions between the base policy and local
customizations.  See prior discussion on Adding local nodecon's through
semanage on selinux list.

-- 
Stephen Smalley
National Security Agency

[refpolicy] [RFC] drop nodecons

[Paul Moore]

On Thursday 08 January 2009 9:17:11 am Stephen Smalley wrote:
> On Wed, 2009-01-07 at 17:20 -0500, Paul Moore wrote:
> > The next step is to get semanage to label network nodes (or fix it
> > if it is broken).
>
> semanage node support exists, but might not correctly handle
> conflicting/overlapping definitions between the base policy and local
> customizations.  See prior discussion on Adding local nodecon's
> through semanage on selinux list.

Yep, I've still got that thread marked in my inbox as something to 
revisit.  It will grow more important once we enable the network peer 
controls policy capability (Chris, thoughts/comments on the patch I 
posted regardint that?).

-- 
paul moore
linux @ hp

[refpolicy] [RFC] drop nodecons

[Christopher J. PeBenito]

On Thu, 2009-01-08 at 10:45 -0500, Paul Moore wrote:
> On Thursday 08 January 2009 9:17:11 am Stephen Smalley wrote:
> > On Wed, 2009-01-07 at 17:20 -0500, Paul Moore wrote:
> > > The next step is to get semanage to label network nodes (or fix it
> > > if it is broken).
> >
> > semanage node support exists, but might not correctly handle
> > conflicting/overlapping definitions between the base policy and local
> > customizations.  See prior discussion on Adding local nodecon's
> > through semanage on selinux list.
> 
> Yep, I've still got that thread marked in my inbox as something to 
> revisit.  It will grow more important once we enable the network peer 
> controls policy capability (Chris, thoughts/comments on the patch I 
> posted regardint that?).

I'm not ready to drop the protocol-specific interfaces.  Refpolicy still
supports back to RHEL4, so the granularity of the original networking
controls is still important.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] [RFC] drop nodecons

[Paul Moore]

On Friday 09 January 2009 8:33:49 am Christopher J. PeBenito wrote:
> On Thu, 2009-01-08 at 10:45 -0500, Paul Moore wrote:
> > On Thursday 08 January 2009 9:17:11 am Stephen Smalley wrote:
> > > On Wed, 2009-01-07 at 17:20 -0500, Paul Moore wrote:
> > > > The next step is to get semanage to label network nodes (or fix
> > > > it if it is broken).
> > >
> > > semanage node support exists, but might not correctly handle
> > > conflicting/overlapping definitions between the base policy and
> > > local customizations.  See prior discussion on Adding local
> > > nodecon's through semanage on selinux list.
> >
> > Yep, I've still got that thread marked in my inbox as something to
> > revisit.  It will grow more important once we enable the network
> > peer controls policy capability (Chris, thoughts/comments on the
> > patch I posted regardint that?).
>
> I'm not ready to drop the protocol-specific interfaces.  Refpolicy
> still supports back to RHEL4, so the granularity of the original
> networking controls is still important.

Okay fair enough.  Let me know what you think about the patch I 
submitted to enable the network_peer_controls policy capability; I'm 
really hoping that we can enable this for F11.

-- 
paul moore
linux @ hp

[refpolicy] [RFC] drop nodecons

[Chris PeBenito]

On Fri, 2009-01-09 at 16:11 -0500, Paul Moore wrote:
> On Friday 09 January 2009 8:33:49 am Christopher J. PeBenito wrote:
> > On Thu, 2009-01-08 at 10:45 -0500, Paul Moore wrote:
> > > On Thursday 08 January 2009 9:17:11 am Stephen Smalley wrote:
> > > > On Wed, 2009-01-07 at 17:20 -0500, Paul Moore wrote:
> > > > > The next step is to get semanage to label network nodes (or fix
> > > > > it if it is broken).
> > > >
> > > > semanage node support exists, but might not correctly handle
> > > > conflicting/overlapping definitions between the base policy and
> > > > local customizations.  See prior discussion on Adding local
> > > > nodecon's through semanage on selinux list.
> > >
> > > Yep, I've still got that thread marked in my inbox as something to
> > > revisit.  It will grow more important once we enable the network
> > > peer controls policy capability (Chris, thoughts/comments on the
> > > patch I posted regardint that?).
> >
> > I'm not ready to drop the protocol-specific interfaces.  Refpolicy
> > still supports back to RHEL4, so the granularity of the original
> > networking controls is still important.
> 
> Okay fair enough.  Let me know what you think about the patch I 
> submitted to enable the network_peer_controls policy capability; I'm 
> really hoping that we can enable this for F11.

As far as I can see, the only related part for that is the hunk that
uncomments the capability.  Perhaps you should resend it?

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090112/2b56a49a/attachment.bin 

[refpolicy] [RFC] drop nodecons

[Paul Moore]

On Monday 12 January 2009 10:34:49 am Chris PeBenito wrote:
> On Fri, 2009-01-09 at 16:11 -0500, Paul Moore wrote:
> > On Friday 09 January 2009 8:33:49 am Christopher J. PeBenito wrote:
> > > On Thu, 2009-01-08 at 10:45 -0500, Paul Moore wrote:
> > > > On Thursday 08 January 2009 9:17:11 am Stephen Smalley wrote:
> > > > > On Wed, 2009-01-07 at 17:20 -0500, Paul Moore wrote:
> > > > > > The next step is to get semanage to label network nodes (or
> > > > > > fix it if it is broken).
> > > > >
> > > > > semanage node support exists, but might not correctly handle
> > > > > conflicting/overlapping definitions between the base policy
> > > > > and local customizations.  See prior discussion on Adding
> > > > > local nodecon's through semanage on selinux list.
> > > >
> > > > Yep, I've still got that thread marked in my inbox as something
> > > > to revisit.  It will grow more important once we enable the
> > > > network peer controls policy capability (Chris,
> > > > thoughts/comments on the patch I posted regardint that?).
> > >
> > > I'm not ready to drop the protocol-specific interfaces. 
> > > Refpolicy still supports back to RHEL4, so the granularity of the
> > > original networking controls is still important.
> >
> > Okay fair enough.  Let me know what you think about the patch I
> > submitted to enable the network_peer_controls policy capability;
> > I'm really hoping that we can enable this for F11.
>
> As far as I can see, the only related part for that is the hunk that
> uncomments the capability.  Perhaps you should resend it?

There was some other small fixes needed to allow unlabeled_t traffic.  
Resending is a good idea, we can continue the discussion then ...

Thanks.

-- 
paul moore
linux @ hp