CentOS7 SELinux doesn't seem to adhere to MCS categories

[Lukas Prediger]

Hello everyone!

I am having some issues with SELinux Multi Category Security on CentOS7
and have been redirected to this mailing list by the folks at
centos.org/forums (as response to my question there [0]).

My problem is the following:
Running CentOS7 64bit with SELinux in enforcing mode in targeted policy,
I noticed that a file that is assigned to a certain SELinux MCS (Multi
Category Security) category can be read by a user who is not assigned to
that category, indicating that MCS isn't working properly.

More specifically, I have users
john | mcsuser_u | s0-s0:c122
jane | mcsuser_u | s0-s0:c123

with
mcsuser_u | MLS/MCS Level: s0 | MLS/MCS Range: s0-s0:c0.c1023 | SELinux
Roles: user_r

and a file
-rw-rw-r-- john john mcsuser_u:object_r:user_home_t:s0:c122 johntext

I would expect that user jane is unable to read the file since she is
not member of the c122 category. However, running cat johntext as jane
prints the contents of the file without problem. This indicates to me
that MCS rules are not adhered to.

I tested the same setup on CentOS 6.9, where everything behaves as I
would expect (i.e., invoking cat johntext as jane results in a permssion
denied error).

Since I was unable to find documentation on a major change in
policy/configuration regarding SELinux from version 6.9 to 7, I am
somewhat confused by this. Am I making an obvious mistake or is this a
bug? If the latter, is it CentOS related or was it some change in
SELinux policies that I did not find documentation on which are present
in the latest versions of CentOS but not in 6.9?

Any advice would be very welcome.

I also posted a more verbose version of this question already on
serverfault.com [1], in case a more detailed listing of my steps is
required.

Thank you very much in advance.

Best regards,
Lukas P.

[0]:
https://www.centos.org/forums/viewtopic.php?f=51&t=66406&sid=31bd...
[1]:
https://serverfault.com/questions/901575/centos7-selinux-doesnt-seem-to-a...

PS: I sent this mail once already last week but didn't get a reply and
it doesn't appear in the archives
[https://lists.fedoraproject.org/archives/], so I'm assuming it got lost
(maybe because I sent it before subscribing to the list..). If it's a
duplicate, please disregard (but maybe point me to / forward me the
responses..)

[Thomas Mueller]

Hi Lukas


On 03/21/2018 10:11 AM, Lukas Prediger wrote:
>  Hello everyone!
>
>  I am having some issues with SELinux Multi Category Security on 
>  CentOS7 and have been redirected to this mailing list by the folks at 
>  centos.org/forums (as response to my question there [0]).
>
>  My problem is the following:
>  Running CentOS7 64bit with SELi
>  
According 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...

I think you need the mls policy not the targeted for MCS enforcement?


- Thomas

[Petr Lautrbach]

On Wed, Mar 21, 2018 at 10:11:11AM +0100, Lukas Prediger wrote:
>  Hello everyone!
>  
>  I am having some issues with SELinux Multi Category Security on CentOS7
>  and have been redirected to this mailing list by the folks at
>  centos.org/forums (as response to my question there [0]).
>  
>  My problem is the following:
>  Running CentOS7 64bit with SELinux in enforcing mode in targeted policy,
>  I noticed that a file that is assigned to a certain SELinux MCS (Multi
>  Category Security) category can be read by a user who is not assigned to
>  that category, indicating that MCS isn't working properly.
>  
>  More specifically, I have users
>  john | mcsuser_u | s0-s0:c122
>  jane | mcsuser_u | s0-s0:c123
>  
>  with
>  mcsuser_u | MLS/MCS Level: s0 | MLS/MCS Range: s0-s0:c0.c1023 | SELinux
>  Roles: user_r
>  
>  and a file
>  -rw-rw-r-- john john mcsuser_u:object_r:user_home_t:s0:c122 johntext
>  
>  I would expect that user jane is unable to read the file since she is
>  not member of the c122 category. However, running cat johntext as jane
>  prints the contents of the file without problem. This indicates to me
>  that MCS rules are not adhered to.
>  
>  I tested the same setup on CentOS 6.9, where everything behaves as I
>  would expect (i.e., invoking cat johntext as jane results in a permssion
>  denied error).
>  
>  Since I was unable to find documentation on a major change in
>  policy/configuration regarding SELinux from version 6.9 to 7, I am
>  somewhat confused by this. Am I making an obvious mistake or is this a
>  bug? If the latter, is it CentOS related or was it some change in
>  SELinux policies that I did not find documentation on which are present
>  in the latest versions of CentOS but not in 6.9?
>  
It seems like a similar problem which was already discussed in this list
https://lists.fedoraproject.org/archives/list/[e-mail]...

If your mcsuser_u maps to user_t you probably need to make user_t mcs
constrained, see the link above.

Petr



>  Any advice would be very welcome.
>  
>  I also posted a more verbose version of this question already on
>  serverfault.com [1], in case a more detailed listing of my steps is
>  required.
>  
>  Thank you very much in advance.
>  
>  Best regards,
>  Lukas P.
>  
>  [0]:
>
> https://www.centos.org/forums/viewtopic.php?f=51&t=66406&sid=31bd...
>  [1]:
>
> https://serverfault.com/questions/901575/centos7-selinux-doesnt-seem-to-a...
>  
>  PS: I sent this mail once already last week but didn't get a reply and
>  it doesn't appear in the archives
>  [https://lists.fedoraproject.org/archives/], so I'm assuming it got lost
>  (maybe because I sent it before subscribing to the list..). If it's a
>  duplicate, please disregard (but maybe point me to / forward me the
>  responses..)
>   
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org

[justina colmena]

On Wed, 21 Mar 2018 11:07:20 +0100
Petr Lautrbach <plautrba(a)redhat.com&gt; wrote:

>  On Wed, Mar 21, 2018 at 10:11:11AM +0100, Lukas Prediger wrote:
>  > More specifically, I have users
>  > john | mcsuser_u | s0-s0:c122
>  > jane | mcsuser_u | s0-s0:c123
>  > 
>  > with
>  > mcsuser_u | MLS/MCS Level: s0 | MLS/MCS Range: s0-s0:c0.c1023 |
>  > SELinux Roles: user_r
>  >  
MLS and MCS were originally intended for top-secret (TS/SCI) government
work at the NSA.

The MLS (Multi-Level Security) corresponds to the levels "s0-s15".
These were supposed to represent various levels of government security
classification, e.g. FOUO, Confidential, Secret, Top Secret.

The MCS (Multi-Category Security) was intended for "Sensitive
Compartmented Information" or "SCI". (Not my department -- I don't
need
to know -- that sort of thing.)

MLS and MCS are not enabled or enforced in the "targeted policy" which
is not intended for heavily targeted systems, but rather to target
scarce open-source SELinux policy development resources at the
hardest-hit and most vulnerable sub-systems.

There has not been much interest in developing open source MLS/MCS
policies for SELinux on end user systems. I'm glad to see someone is
tinkering with it.

[Gionatan Danti]

Il 21-03-2018 17:16 justina colmena ha scritto:
>  MLS and MCS were originally intended for top-secret (TS/SCI)
> government
>  work at the NSA.
>  
>  The MLS (Multi-Level Security) corresponds to the levels "s0-s15".
>  These were supposed to represent various levels of government security
>  classification, e.g. FOUO, Confidential, Secret, Top Secret.
>  
>  The MCS (Multi-Category Security) was intended for "Sensitive
>  Compartmented Information" or "SCI". (Not my department -- I don't
> need
>  to know -- that sort of thing.)
>  
>  MLS and MCS are not enabled or enforced in the "targeted policy" which
>  is not intended for heavily targeted systems, but rather to target
>  scarce open-source SELinux policy development resources at the
>  hardest-hit and most vulnerable sub-systems.
>  
>  There has not been much interest in developing open source MLS/MCS
>  policies for SELinux on end user systems. I'm glad to see someone is
>  tinkering with it. 
But why it does work on CentOS6?
What can be done to let it work on CentOS7?
Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8

[Gary Tierney]

On Wed, Mar 21, 2018 at 10:13:56PM +0100, Gionatan Danti wrote:
> Il 21-03-2018 17:16 justina colmena ha scritto:
> >MLS and MCS were originally intended for top-secret (TS/SCI) government
> >work at the NSA.
> >
> >The MLS (Multi-Level Security) corresponds to the levels "s0-s15".
> >These were supposed to represent various levels of government security
> >classification, e.g. FOUO, Confidential, Secret, Top Secret.
> >
> >The MCS (Multi-Category Security) was intended for "Sensitive
> >Compartmented Information" or "SCI". (Not my department -- I don't
> need
> >to know -- that sort of thing.)
> >
> >MLS and MCS are not enabled or enforced in the "targeted policy" which
> >is not intended for heavily targeted systems, but rather to target
> >scarce open-source SELinux policy development resources at the
> >hardest-hit and most vulnerable sub-systems.
> >
> >There has not been much interest in developing open source MLS/MCS
> >policies for SELinux on end user systems. I'm glad to see someone is
> >tinkering with it.
>
> But why it does work on CentOS6?
> What can be done to let it work on CentOS7?
> Thanks.
>  
Back in CentOS 6 every type was considered an "MCS constrained" type by
default.

CentOS 7 changed that behaviour by adding some constraints that only
considered a type MCS constrained if it was associated with a given attribute
(see: https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/mcs#L73).
So now category/compartment dominance is only considered if you have an
association between your type and the MCS attribute.

You can see a list of these MCS constrained types by using seinfo:

$ seinfo -xamcs_constrained_type
Type Attributes: 1
  attribute mcs_constrained_type;
       container_t
       netlabel_peer_t
       openshift_app_t
       { ... }

If you want to create an association of your own, you can create a new policy
module like this:

$ echo '(typeattributeset mcs_constrained_type my_type)' > my_mcs_policy.cil
$ semodule -i my_mcs_policy.cil

>-- 
>Danti Gionatan
>Supporto Tecnico
>Assyoma S.r.l. - www.assyoma.it
>email: g.danti(a)assyoma.it - info(a)assyoma.it
>GPG public key ID: FF5F32A8
>_______________________________________________
>selinux mailing list -- selinux(a)lists.fedoraproject.org
>To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org

[Gionatan Danti]

Il 21-03-2018 22:32 Gary Tierney ha scritto:
>  Back in CentOS 6 every type was considered an "MCS
> constrained" type by
>  default.
>  
>  CentOS 7 changed that behaviour by adding some constraints that only
>  considered a type MCS constrained if it was associated with a given 
>  attribute
>  (see:
>  https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/mcs#L73).
>  So now category/compartment dominance is only considered if you have an
>  association between your type and the MCS attribute. 
Interesting. What is/was the reasoning behind the change? I would 
naively expect a CentOS6-like approach rather than the new one. Is is 
possible to revert the the old behavior with something as an 
all-or-nothing switch?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8

[Simon Sekidde]

----- Original Message -----
>  From: "Gionatan Danti" <g.danti(a)assyoma.it&gt;
>  To: "Gary Tierney" <gary.tierney(a)gmx.com&gt;
>  Cc: selinux(a)lists.fedoraproject.org
>  Sent: Wednesday, March 21, 2018 6:41:57 PM
>  Subject: Re: CentOS7 SELinux doesn't seem to adhere to MCS categories
>  
>  Il 21-03-2018 22:32 Gary Tierney ha scritto:
>  > Back in CentOS 6 every type was considered an "MCS constrained" type by
>  > default.
>  > 
>  > CentOS 7 changed that behaviour by adding some constraints that only
>  > considered a type MCS constrained if it was associated with a given
>  > attribute
>  > (see:
>  > https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/mcs#L73).
>  > So now category/compartment dominance is only considered if you have an
>  > association between your type and the MCS attribute.
>  
>  Interesting. What is/was the reasoning behind the change? I would
>  naively expect a CentOS6-like approach rather than the new one. Is is
>  possible to revert the the old behavior with something as an
>  all-or-nothing switch?
>   
The answer/reason for the change is under 'MCS Is different then type
enforcement.' in the link below

https://danwalsh.livejournal.com/73416.html


>  Thanks.
>  
>  --
>  Danti Gionatan
>  Supporto Tecnico
>  Assyoma S.r.l. - www.assyoma.it
>  email: g.danti(a)assyoma.it - info(a)assyoma.it
>  GPG public key ID: FF5F32A8
>  _______________________________________________
>  selinux mailing list -- selinux(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
>   
-- 
Simon Sekidde 
gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E

[Lukas Prediger]

Am 22.03.2018 um 00:20 schrieb Simon Sekidde:
>  ----- Original Message -----
> > From: "Gionatan Danti" <g.danti(a)assyoma.it&gt;
> > To: "Gary Tierney" <gary.tierney(a)gmx.com&gt;
> > Cc: selinux(a)lists.fedoraproject.org
> > Sent: Wednesday, March 21, 2018 6:41:57 PM
> > Subject: Re: CentOS7 SELinux doesn't seem to adhere to MCS categories
> >
> > Il 21-03-2018 22:32 Gary Tierney ha scritto:
> >> Back in CentOS 6 every type was considered an "MCS constrained" type
> by
> >> default.
> >>
> >> CentOS 7 changed that behaviour by adding some constraints that only
> >> considered a type MCS constrained if it was associated with a given
> >> attribute
> >> (see:
> >> https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/mcs#L73).
> >> So now category/compartment dominance is only considered if you have an
> >> association between your type and the MCS attribute.
> > Interesting. What is/was the reasoning behind the change? I would
> > naively expect a CentOS6-like approach rather than the new one. Is is
> > possible to revert the the old behavior with something as an
> > all-or-nothing switch?
> > 
First of all I want to say thanks to all of you for the insights.
Writing a custom policy to add the mcs_constrained_type to user_t indeed
led to the expected behavior and blocked john from accessing jane's file
(and vice versa), so thanks for pointing that out.

I feel, however, that this could've been pointed out in the
documentation somewhere.. in all documents I found googling, this was
not mentioned; the only reference I've seen was in the article by Dan
Walsh linked above which is not as authoritative a source as the
official distribution docs (at least not to a layman like me) (meaning:
I didn't know of that blog and didn't come across that article while
searching).

I admit that I am also a bit puzzled by the decision to apply mcs to
only some types instead of all of them. I don't really see a benefit in
that and I think it makes using MCS unneccessarily more
complex/difficult, which is unfortunate because in my opinion it's a
useful feature.
I also respectfully disagree with
>  The answer/reason for the change is under 'MCS Is different then
> type enforcement.' in the link below
>
>  https://danwalsh.livejournal.com/73416.html 
There it only states "We decided not to apply MCS Separation to every
type.    We only apply it to the types that we plan on running in a
Multi-Tennant way.  Basically it is for objects that we want to share
the same access to the system, but not to each other." In my opinion
that's not a reason but just a somewhat arbitrary decision and thus not
an answer to the question.. I do, however, also believe that the folks
working on SELinux are smart people and know more about the matters
involved than I do, so maybe there are valid reasons that are just not
communicated well.. in which case I would like to hear (or rather read)
them stated in a concise way.

As I said, I don't think there's any downside to applying MCS to all
types, quite the contrary: if you don't assign category labels to a file
(label: s0) (or process/user/etc), it doesn't matter whether MCS checks
are applied or not, but you can benefit from MCS for any type by just
adding labels without any further actions.
So, if anyone can shed some light on the reasoning behind the decision
(or point me to someone willing/able to do so), I'd be thankful for that.

Finally, I also noticed that the restorecon tool does not relabel files
if only the MCS label differs without passing the force argument (-F),
which is also a bit confusing at first. (I changed the label (but not
type or user) using semanage fcontext and tried changing using
restorecon with no effect. If I also changed the type with fcontext,
both, type and label, where changed.) This is true for both CentOS
versions (6.9 and 7) in the targeted policy. My guess is that restorecon
doesn't look at the MCS label while determining which files need to be
updated/restored, so I wanted call that to attention.

This concludes my text wall.. thanks for reading all of it if you've
made it this far and also thanks again for all the replies to my first
e-mail. I'm looking forward to more of those.

Kind regards,
Lukas P.