All of lore.kernel.org
 help / color / mirror / Atom feed
From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [RFC] drop nodecons
Date: Wed, 07 Jan 2009 15:24:16 -0500	[thread overview]
Message-ID: <1231359858.7517.30.camel@gorn> (raw)
In-Reply-To: <200901071421.35901.paul.moore@hp.com>

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

  reply	other threads:[~2009-01-07 20:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-07 15:25 [refpolicy] [RFC] drop nodecons Christopher J. PeBenito
2009-01-07 19:21 ` Paul Moore
2009-01-07 20:24   ` Christopher J. PeBenito [this message]
2009-01-07 22:20     ` Paul Moore
2009-01-08 14:17       ` Stephen Smalley
2009-01-08 15:45         ` Paul Moore
2009-01-09 13:33           ` Christopher J. PeBenito
2009-01-09 21:11             ` Paul Moore
2009-01-12 15:34               ` Chris PeBenito
2009-01-14 16:09                 ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1231359858.7517.30.camel@gorn \
    --to=cpebenito@tresys.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.