selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Paul Tagliamonte <paultag@debian.org>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: Documentation on Enabling NetLabel
Date: Wed, 20 May 2020 14:39:49 -0400	[thread overview]
Message-ID: <CAHC9VhQUYVmsXgXUqi6CUa2Np68-PajDkzd7BsDGk7kxLz+Uiw@mail.gmail.com> (raw)
In-Reply-To: <20200520165322.GA225268@nyx>

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

  reply	other threads:[~2020-05-20 18:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 16:53 Documentation on Enabling NetLabel Paul Tagliamonte
2020-05-20 18:39 ` Paul Moore [this message]
2020-05-21 17:16   ` Paul Tagliamonte
2020-05-22 17:17     ` 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=CAHC9VhQUYVmsXgXUqi6CUa2Np68-PajDkzd7BsDGk7kxLz+Uiw@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=paultag@debian.org \
    --cc=selinux@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).