Re: Documentation on Enabling NetLabel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 20, 2020 at 12:53 PM Paul Tagliamonte <paultag@xxxxxxxxxx> 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



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux