Documentation on Enabling NetLabel

Documentation on Enabling NetLabel

[Paul Tagliamonte]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

Hey SELinux folks,

Sorry for the second email in no time, but I'm a bit stuck and could use
some pointers to continue my quest to get NetLabel working on a Debian
VM, and send patches to make it easier for others in the future :)

I have SELinux and MLS working (even to some degree whilst enforcing!)
in a VM, generally speaking. I can ssh in and do normal things. The
rules need a bit more love, but it's in a fine state that I'm happy
working from.

I've been able to set up NetLabel to attach a security connect to
connections (nice!) that show up when querying the peer context, but switching
from permissive to `1` results in dropped traffic.

I'm sure this is likely the result of (correct!) filtering going on, and
because it's now gone from no context to a context, traffic is likely
getting filtered out. I don't see anything in audit2why in permissive
mode, but I also don't know if invalid network activity is logged.

I've tried tcpdump on the host, to no avail. I see packets going in, and
not much coming out. I've kept the kernel on the VM host on a version that
doesn't have NETLABEL enabled, in an effort to not have the host kernel get
in the way.

Specifically, I've tried:

```
netlabelctl cipsov4 add local doi:2
netlabelctl unlbl accept on

netlabelctl map del default
netlabelctl map add default address:0.0.0.0/0 protocol:unlbl
netlabelctl map add default address:::/0 protocol:unlbl
netlabelctl map add default address:10.128.0.0/24 protocol:unlbl
netlabelctl map add default address:127.0.0.1 protocol:cipsov4,2
```


On localhost, I can't connect to any running daemons (such as SSH), and
I've specifically not added the NIC that is bridged to my LAN (in a maybe
misguided attempt to keep traffic from the LAN unmarked) to any netlabel
rules. I was also unable to connect to the OpenSSH server via the
network IP either.

When enforcing without running the above netlabel commands, I can ssh into the
box successfully.

Thanks for any help anyone can provide, and thank you all very much for
being so helpful for my last question!

    paultag

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `-     http://people.debian.org/~paultag

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Documentation on Enabling NetLabel

[Paul Moore]

On Wed, May 20, 2020 at 12:53 PM Paul Tagliamonte <paultag@debian.org> wrote:
> Hey SELinux folks,
>
> Sorry for the second email in no time, but I'm a bit stuck and could use
> some pointers to continue my quest to get NetLabel working on a Debian
> VM, and send patches to make it easier for others in the future :)
>
> I have SELinux and MLS working (even to some degree whilst enforcing!)
> in a VM, generally speaking. I can ssh in and do normal things. The
> rules need a bit more love, but it's in a fine state that I'm happy
> working from.
>
> I've been able to set up NetLabel to attach a security connect to
> connections (nice!) that show up when querying the peer context, but switching
> from permissive to `1` results in dropped traffic.
>
> I'm sure this is likely the result of (correct!) filtering going on, and
> because it's now gone from no context to a context, traffic is likely
> getting filtered out. I don't see anything in audit2why in permissive
> mode, but I also don't know if invalid network activity is logged.

Presumably it works when you are in permissive mode but fails when you
are in enforcing mode, or does it fail in permissive too?

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

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.

> I've tried tcpdump on the host, to no avail. I see packets going in, and
> not much coming out. I've kept the kernel on the VM host on a version that
> doesn't have NETLABEL enabled, in an effort to not have the host kernel get
> in the way.
>
> Specifically, I've tried:
>
> ```
> netlabelctl cipsov4 add local doi:2
> netlabelctl unlbl accept on
>
> netlabelctl map del default
> netlabelctl map add default address:0.0.0.0/0 protocol:unlbl
> netlabelctl map add default address:::/0 protocol:unlbl
> netlabelctl map add default address:10.128.0.0/24 protocol:unlbl
> netlabelctl map add default address:127.0.0.1 protocol:cipsov4,2
> ```

It's not clear which interface you sniffed, was it the loopback
interface?  That is the only interface which should be doing any
explicit labeling; if you see CIPSO IP options on non-loopback
interfaces something is wrong.  I would also expect you to see CIPSO
options on the loopback traffic, do you?

As an aside, Wireshark does know how to parse CIPSO options so you
should be able to peek at them that way; although Wireshark does not
know about the "local" tag type we use on loopback (... and it
shouldn't, it's a horrible abuse of CIPSO, done intentionally <g>).

> On localhost, I can't connect to any running daemons (such as SSH), and
> I've specifically not added the NIC that is bridged to my LAN (in a maybe
> misguided attempt to keep traffic from the LAN unmarked) to any netlabel
> rules. I was also unable to connect to the OpenSSH server via the
> network IP either.

Try removing the dontaudit rules (above) and see if that helps with
the AVCs.  Let us know what you find.

> When enforcing without running the above netlabel commands, I can ssh into the
> box successfully.
>
> Thanks for any help anyone can provide, and thank you all very much for
> being so helpful for my last question!

-- 
paul moore
www.paul-moore.com

Re: Documentation on Enabling NetLabel

[Paul Tagliamonte]

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]

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.

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

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.

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

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.

> That is the only interface which should be doing any
> explicit labeling; if you see CIPSO IP options on non-loopback
> interfaces something is wrong.  I would also expect you to see CIPSO
> options on the loopback traffic, do you?

I believe so, but I wasn't sniffing inside the VM because my SELinux
rules need to be fixed :)

It certently works in permissive mode, and I'd expect it works in
enforcing mode, but it's tough to tell right now. I'll see if I can put
a rule in place to start up a getpeercon daemon and see what it says.

> As an aside, Wireshark does know how to parse CIPSO options so you
> should be able to peek at them that way; although Wireshark does not
> know about the "local" tag type we use on loopback (... and it
> shouldn't, it's a horrible abuse of CIPSO, done intentionally <g>).

Roger that :)

> Try removing the dontaudit rules (above) and see if that helps with
> the AVCs.  Let us know what you find.

Will do, I'll dig deeper, and come back with something a bit more
specific. I think between that and the unlabelednet module, I've got
some debugging to do.


   paultag

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `-     http://people.debian.org/~paultag

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Documentation on Enabling NetLabel

[Paul Moore]

On Thu, May 21, 2020 at 1:16 PM Paul Tagliamonte <paultag@debian.org> 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.

* https://www.paul-moore.com/blog/d/2009/02/netlabel_address_selectors.html

-- 
paul moore
www.paul-moore.com