SELinux Archive on
 help / color / Atom feed
From: Paul Moore <>
To: Paul Tagliamonte <>
Cc: SElinux list <>
Subject: Re: Documentation on Enabling NetLabel
Date: Fri, 22 May 2020 13:17:35 -0400
Message-ID: <> (raw)
In-Reply-To: <20200521171627.GA326433@nyx>

On Thu, May 21, 2020 at 1:16 PM Paul Tagliamonte <> wrote:
> On Wed, May 20, 2020 at 02:39:49PM -0400, Paul Moore wrote:
> > Presumably it works when you are in permissive mode but fails when you
> > are in enforcing mode, or does it fail in permissive too?
> That's correct, everything seems A-OK in permissive mode, and starts to
> get denied (likely correctly) in enforcing mode.
> > If it works in permissive mode but you aren't seeing any AVC failures,
> > you may want to try removing the dontaudit rules from the policy.  You
> > can do that via 'semodule -DB' (the semodule(8) manpage has some
> > examples).
> Just tried that, thank you for the suggestion! I don't see any
> additional logging, but I'm going to follow up more comprehensively
> after reading the documentation. I'll give this a stronger go tonight.

Okay, let us know what you find out.  I'm a little concerned that you
didn't see any additional AVC denials in the logs; if the system is
working in permissive and you're not seeing any denials with the
dontaudits removed something is off.

> > You may find that in the near term you need something like Fedora's
> > unlabelednet policy module which blanket allows unlabeled network
> > traffic to all the domains on the system.
> Ah! This makes _so much_ sense. I was wondering where rules defining
> this behavior lived. Looks like it's a (very comprenstive?) RH specific
> changeset that we don't carry in Debian. I've got some work cut out for
> me from the looks of it.

The basic idea is that you have some type attribute which represents
all the domains on the system and you grant that attribute the ability
to talk to unlabeled traffic.  Perhaps the Fedora patch might not be a
direct fit, but I imagine you could do something very similar for
Debian without too much difficulty (warning: I'm saying this without
looking at the Debian policy).

However, it is worth mentioning again that this approach allows
unlabeled traffic *everywhere* and isn't really suitable for a system
in a proper labeled network (it somewhat defeats the purpose of
setting up labeling in the first place).

> I started to graft sections I thought were relevent from policy-rhel-7.2-base.patch
> into my local policies, but I think I'm super in over my head. This is
> likely going to take me some time to work through, but it's monumentally
> helpful. I was only looking at the upstream rules and our package, which
> explains why I was missing a lot of this.
> I assume since this is being maintained by a lot of folks working
> upstream too which makes me suspect this is a WONTFIX situation
> with the upstream rules. Seems like I ought to tread lightly here.

I'm not sure I would jump to the same conclusion.  First the RHEL 7.x
policy, like RHEL 7.x in general, is quite old; second, while we do
regularly perform some basic labeled networking tests as part of the
SELinux test suite, it definitely doesn't get the same level of
everyday testing that other parts of SELinux receive.

If you hit a problem you can't solve don't be afraid to speak up.
Either it's something in your policy we can (hopefully) help you
resolve, or it's a real bug in the system that we can (hopefully) get
fixed for everyone.

> > It's not clear which interface you sniffed, was it the loopback
> > interface?
> I was sniffing from the VM Host (a laptop) to see what was coming in/out
> of the network when I tried to initiate an SSH connection from the LAN
> to the VM, since that *should* be unlabeled and pass through (although
> given the bit above about the default unlabeled rules, it's likely
> getting filtered out).

Depending on the age of the kernel on your host, there *may* be issues
with it passing CIPSO traffic properly, even if it isn't configured
(there were bugs in older kernels that have since been fixed).
However, since you're not sending CIPSO traffic outside the guest this
shouldn't be an issue.

> I was trying to minimally set up labeling for localhost (without
> impacting the LAN NIC) to make a baby step in enabling NetLabel with
> enforcement on, and still allowing network I/O except where I was
> placing specific rules in place.

If you want to take even smaller steps, you can combine the NetLabel
domain and address selectors such that only specific apps/domains will
send labeled traffic over loopback.


paul moore

      reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 16:53 Paul Tagliamonte
2020-05-20 18:39 ` Paul Moore
2020-05-21 17:16   ` Paul Tagliamonte
2020-05-22 17:17     ` Paul Moore [this message]

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:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

SELinux Archive on

Archives are clonable:
	git clone --mirror selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ \
	public-inbox-index selinux

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone