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=31bd377... [1]: https://serverfault.com/questions/901575/centos7-selinux-doesnt-seem-to-adhe...
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..)
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/htm... I think you need the mls policy not the targeted for MCS enforcement?
- Thomas
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/selinux@lists.fedoraproject.or...
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.
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@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
On Wed, 21 Mar 2018 11:07:20 +0100 Petr Lautrbach plautrba@redhat.com 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.
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.
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@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8 _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
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.
----- Original Message -----
From: "Gionatan Danti" g.danti@assyoma.it To: "Gary Tierney" gary.tierney@gmx.com Cc: selinux@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@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8 _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
Am 22.03.2018 um 00:20 schrieb Simon Sekidde:
----- Original Message -----
From: "Gionatan Danti" g.danti@assyoma.it To: "Gary Tierney" gary.tierney@gmx.com Cc: selinux@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
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.
selinux@lists.fedoraproject.org
-
Gary Tierney -
Gionatan Danti -
justina colmena -
Lukas Prediger -
Petr Lautrbach -
Simon Sekidde -
Thomas Mueller