MCS NetLabel

MCS NetLabel

[Paul R. Tagliamonte]

Hello SELinux folks,

I'm running a test system using MCS and just starting to get to the
point where I'm interested in enabling NetLabel + CIPSO to pass along
context on a LAN. As a first step, I was able to get it working off
`localhost` before adding in CIPSO or other boxen.

I'm able to run in enforcing mode (amazing!) and get the peer context
(even more amazing!) -- which I can use to calculate the effective
"connection context" for logical filtering on common categories.
That's really great!

I'm a bit confused with some of the enforcement on this, though. When
I run my server (with a user and binary at the level of `s0:c1`),
connecting to localhost via a user at `s0` results in a connection
getting established.

While I understand this isn't the same as MLS / sensitivity level, I'm
a bit surprised that it didn't refuse to connect to the privileged
resource. Certainly I can't cat a file from a user at `s0` that's at
`s0:c1`, or likely (I haven't tried, but it stands to reason) a UNIX
Socket with `c1` -- so the TCP connection going through was a bit
surprising. I can see in the peer context that the user is at `s0`
(without `c1`), so it'd be possible to filter this software-side, but
it'd also be a bit more of a mental relief if only processes with the
`c1` category could connect.

Is there any documentation on how to set that particular type of enforcement?

Thank you all very much!
  Paul


-- 
:wq

Re: MCS NetLabel

[Paul Moore]

On Sun, Apr 18, 2021 at 4:02 PM Paul R. Tagliamonte <paultag@gmail.com> wrote:
> Hello SELinux folks,

Hello fellow Paul.

> I'm running a test system using MCS and just starting to get to the
> point where I'm interested in enabling NetLabel + CIPSO to pass along
> context on a LAN. As a first step, I was able to get it working off
> `localhost` before adding in CIPSO or other boxen.
>
> I'm able to run in enforcing mode (amazing!) and get the peer context
> (even more amazing!) -- which I can use to calculate the effective
> "connection context" for logical filtering on common categories.
> That's really great!

I'll admit to being a bit biased, but yeah, it is pretty cool ;)

However, there are a few words of caution I should share.  First, you
will want to make sure that you protect your IPv4 header if you are
sending CIPSO traffic across an untrusted network.  Second, you need
to make sure that any of your network hops/middle-boxes don't strip
IPv4 options; if they do, you'll lose your CIPSO labels.  The good
news is that in both cases encapsulating your network traffic in a VPN
or some other form of protected tunnel should solve both problems.  If
you use IPv6, CALIPSO has similar concerns, although due to the nature
of CALIPSO and IPv6 the middle-box problem shouldn't really be an
issue.

There is also labeled IPsec, but it is SELinux only and if you don't
carefully synchronize your policies across nodes you can get into some
odd/dangerous situations.  People really like labeled IPsec because
you can transmit the full SELinux label over the wire and not just the
MLS/MCS information, but it's a bad design IMHO; you're better off
with CIPSO/CALIPS+IPsec if you can get by with just the MLS/MCS
information.

> I'm a bit confused with some of the enforcement on this, though. When
> I run my server (with a user and binary at the level of `s0:c1`),
> connecting to localhost via a user at `s0` results in a connection
> getting established.
>
> While I understand this isn't the same as MLS / sensitivity level, I'm
> a bit surprised that it didn't refuse to connect to the privileged
> resource. Certainly I can't cat a file from a user at `s0` that's at
> `s0:c1`, or likely (I haven't tried, but it stands to reason) a UNIX
> Socket with `c1` -- so the TCP connection going through was a bit
> surprising. I can see in the peer context that the user is at `s0`
> (without `c1`), so it'd be possible to filter this software-side, but
> it'd also be a bit more of a mental relief if only processes with the
> `c1` category could connect.
>
> Is there any documentation on how to set that particular type of enforcement?

You didn't mention what distro and/or policy you are using (other than
MCS), but my guess is you are running into a situation where the
SELinux policy constraints are not set as expected.  I know in the
past the MCS labeled networking constraints were a bit lax, even
outright missing at one point, so that would be a good place to start.

However, since most people are a bit lost when it comes to policy
constraints, let me introduce you to The SELinux Notebook:

* https://github.com/SELinuxProject/selinux-notebook

... it is an *amazing* freely available resource, that I would
encourage you to take a look at if you haven't already.  It's source
material is in GitHub friendly Markdown, and you can render it into
HTML and PDF if you like using the provided Makefile.  The Notebook
has a section on policy constraints where it provides some expalantion
of the "mlscontrain" statement, which I believe is where your problem
lies:

* https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md
* https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md#mlsconstrain

... from there it is a matter of inspecting your policy to see what it
specifies for the MLS/MCS network controls - good luck!

-- 
paul moore
www.paul-moore.com

Re: MCS NetLabel

[Paul R. Tagliamonte]

[ Resending -- my email was HTML and got rejected. Sorry for two
emails, Paul :) ]

On Sun, Apr 18, 2021 at 5:19 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Sun, Apr 18, 2021 at 4:02 PM Paul R. Tagliamonte <paultag@gmail.com> wrote:
> > Hello SELinux folks,
>
> Hello fellow Paul.

Ah! Paul! A true pleasure -- and thanks again for all your documentation! I
wouldn't be nearly as far as I am without you. I hope you know how many of
us out here are very grateful for your tireless work, Paul!

> I'll admit to being a bit biased, but yeah, it is pretty cool ;)
>
> However, there are a few words of caution I should share.  First, you
> will want to make sure that you protect your IPv4 header if you are
> sending CIPSO traffic across an untrusted network.  Second, you need
> to make sure that any of your network hops/middle-boxes don't strip
> IPv4 options; if they do, you'll lose your CIPSO labels.  The good
> news is that in both cases encapsulating your network traffic in a VPN
> or some other form of protected tunnel should solve both problems.  If
> you use IPv6, CALIPSO has similar concerns, although due to the nature
> of CALIPSO and IPv6 the middle-box problem shouldn't really be an
> issue.

Understood on all counts, thank you very much!

> There is also labeled IPsec, but it is SELinux only and if you don't
> carefully synchronize your policies across nodes you can get into some
> odd/dangerous situations.  People really like labeled IPsec because
> you can transmit the full SELinux label over the wire and not just the
> MLS/MCS information, but it's a bad design IMHO; you're better off
> with CIPSO/CALIPS+IPsec if you can get by with just the MLS/MCS
> information.

Got it. That's super helpful, thanks.

> You didn't mention what distro and/or policy you are using (other than
> MCS), but my guess is you are running into a situation where the
> SELinux policy constraints are not set as expected.  I know in the
> past the MCS labeled networking constraints were a bit lax, even
> outright missing at one point, so that would be a good place to start.

I'm running Debian sid -- which I am fully eyes-open about how stale
and/or actively busted our policy is. I don't think too many people have
MCS configured on their systems, so it's not going to be a huge shock
to me when this is part of the root cause here.

I have a pile of stuff I'm loading in even to get stuff to where I'm at
now, and I think long-term I'll likely try to start agitating on ways to
get Debian's policy a bit more up to date. That's a windmill for another
day, though, I think. Our SELinux maintainers work very hard and
I don't want to add work for them without being able to pitch in.

I've uploaded netlabel-tools to Debian[1] back in October, and I've been
playing a bit with netlabel on my home network (both to get better
at SELinux generally an CIPSO/CALIPSO/NetLabel specifically)
so I can effectively triage/debug issues in Debian.

I know basically no one is in the same boat as me, and I'm OK with that :)

> However, since most people are a bit lost when it comes to policy
> constraints, let me introduce you to The SELinux Notebook:
>
> * https://github.com/SELinuxProject/selinux-notebook
>
> ... it is an *amazing* freely available resource, that I would
> encourage you to take a look at if you haven't already.  It's source
> material is in GitHub friendly Markdown, and you can render it into
> HTML and PDF if you like using the provided Makefile.  The Notebook
> has a section on policy constraints where it provides some expalantion
> of the "mlscontrain" statement, which I believe is where your problem
> lies:

Amazing. Lovely. Thank you! I will be sure to go through this and work
through issues as I find them. Thanks for the pointer, I hadn't found this
yet!

> * https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md
> * https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md#mlsconstrain
>
> ... from there it is a matter of inspecting your policy to see what it
> specifies for the MLS/MCS network controls - good luck!

Perfect. Thanks, Paul!
   [Mirror Universe] Paul

> --
> paul moore
> www.paul-moore.com

[1]: https://tracker.debian.org/pkg/netlabel-tools

--
:wq

Re: MCS NetLabel

[Paul Moore]

On Sun, Apr 18, 2021 at 5:56 PM Paul R. Tagliamonte <paultag@gmail.com> wrote:
> On Sun, Apr 18, 2021 at 5:19 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Sun, Apr 18, 2021 at 4:02 PM Paul R. Tagliamonte <paultag@gmail.com> wrote:
> > > Hello SELinux folks,
> >
> > Hello fellow Paul.
>
> Ah! Paul! A true pleasure -- and thanks again for all your documentation! I
> wouldn't be nearly as far as I am without you. I hope you know how many of
> us out here are very grateful for your tireless work, Paul!

Thank you, that's very nice of you to say, but Richard Haines and the
other Notebook contributors are the ones who deserve the credit (check
the git log, not everyone adds their name to the copyright page!).
Richard was kind enough to put together The SELinux Notebook in the
first place and offer it under a public license; my role thus far has
simply been to post it to GitHub on behalf of Richard, do some minor
cleanup, tweak the HTML/PDF CSS a bit, and merge patches as they hit
the list.

The SELinux project is very fortunate to have a good sized community
with a number of contributors, and I'm very happy to say we've made
some big improvements to documentation and testing over the past few
years.

> > You didn't mention what distro and/or policy you are using (other than
> > MCS), but my guess is you are running into a situation where the
> > SELinux policy constraints are not set as expected.  I know in the
> > past the MCS labeled networking constraints were a bit lax, even
> > outright missing at one point, so that would be a good place to start.
>
> I'm running Debian sid -- which I am fully eyes-open about how stale
> and/or actively busted our policy is. I don't think too many people have
> MCS configured on their systems, so it's not going to be a huge shock
> to me when this is part of the root cause here.
>
> I have a pile of stuff I'm loading in even to get stuff to where I'm at
> now, and I think long-term I'll likely try to start agitating on ways to
> get Debian's policy a bit more up to date. That's a windmill for another
> day, though, I think. Our SELinux maintainers work very hard and
> I don't want to add work for them without being able to pitch in.

I've long wanted to start doing regular testing of the bleeding edge
kernel bits (the "kernel-secnext" testing) on Debian as well as
Fedora.  While Fedora has been an excellent "home" for SELinux
development, I think it is important that we strive to bring that same
SELinux experience to other distros too.  Debian seemed to be an
obvious next choice to me, and while the kernel-secnext testing is
only a small part of that I'm hopeful it will have a positive impact
on the effort ... when I get some time to do that of course :/

> I've uploaded netlabel-tools to Debian[1] back in October, and I've been
> playing a bit with netlabel on my home network (both to get better
> at SELinux generally an CIPSO/CALIPSO/NetLabel specifically)
> so I can effectively triage/debug issues in Debian.
>
> I know basically no one is in the same boat as me, and I'm OK with that :)

We're all in different boats, and I think that's a good thing :)

> > However, since most people are a bit lost when it comes to policy
> > constraints, let me introduce you to The SELinux Notebook:
> >
> > * https://github.com/SELinuxProject/selinux-notebook
> >
> > ... it is an *amazing* freely available resource, that I would
> > encourage you to take a look at if you haven't already.  It's source
> > material is in GitHub friendly Markdown, and you can render it into
> > HTML and PDF if you like using the provided Makefile.  The Notebook
> > has a section on policy constraints where it provides some expalantion
> > of the "mlscontrain" statement, which I believe is where your problem
> > lies:
>
> Amazing. Lovely. Thank you! I will be sure to go through this and work
> through issues as I find them. Thanks for the pointer, I hadn't found this
> yet!

If you find any problems, or have some text that you think would be a
nice addition, patches are always welcome :)

-- 
paul moore
www.paul-moore.com