Am 22.03.2018 um 00:20 schrieb Simon Sekidde: > > ----- Original Message ----- >> From: "Gionatan Danti" <g.danti@xxxxxxxxxx> >> To: "Gary Tierney" <gary.tierney@xxxxxxx> >> Cc: selinux@xxxxxxxxxxxxxxxxxxxxxxx >> 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. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
