Am 22.03.2018 um 00:20 schrieb Simon Sekidde:
----- Original Message -----
> From: "Gionatan Danti" <g.danti(a)assyoma.it>
> To: "Gary Tierney" <gary.tierney(a)gmx.com>
> 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
>> CentOS 7 changed that behaviour by adding some constraints that only
>> considered a type MCS constrained if it was associated with a given
>> 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
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
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.