On 03/08/2018 04:01 PM, justina colmena wrote: > On Wednesday, March 7, 2018 2:26:14 PM AKST m.roth@xxxxxxxxx wrote: >> Stephen Smalley wrote: >> >>> On 03/07/2018 03:18 PM, m.roth@xxxxxxxxx wrote: >>> >>>> CentUS 7.4 >>>> ... >>>> From sealert: >>>> SELinux is preventing /usr/sbin/sshd from read access on the file >>>> /etc/ssh/moduli. >>>> Except: >>>> ls -laFZ /etc/ssh/moduli >>>> -rw-r--r--. root root system:object_r:etc_t:s0 /etc/ssh/moduli >>> ... >>> NB: You have "system" rather than "system_u" above, unless that's a typo. >>> Which would be an invalid user identity, and thus an invalid security >>> context, and therefore mapped to the unlabeled context at runtime. > > CentUS or CentOS? "system" or "system_u"? Am I to be amused? > > This is frustrating. This sort of thing is typical of a hacked system, and for > us ordinary users, there is no sane SELinux policy development taking place. A > lot of these security labels can easily, freely, and arbitrarily be changed by > ordinary users with the "chcon" command, there is a lot of covert resistance > to locking things down any further or fixing persistent security problems, and > SELinux has never really moved beyond the philosophy of > > # touch /.autorelabel && reboot I'm not dismissing your frustration or saying that it isn't legitimate, but I did want to clarify a few points: 1) chcon should almost never be used by users. restorecon (possibly preceded by a semanage fcontext -a to add the entry to file_contexts if needed) is preferred. I know that at least in the past, incorrect/poor guidance has been given by setroubleshoot in this area; hopefully that has been fixed - if not, that's a bug in setroubleshoot (which I have nothing to do with). 2) Ordinary users should not have been able to change the context of a root-owned file, regardless of whether they are confined by SELinux; there is still a DAC check on setting file contexts. 3) Users in confined roles can be prevented from changing file contexts, even to their own files. This is not the default in Fedora, but you can assign confined roles to users via semanage login and/or system-config-selinux, and can introduce your own roles. 4) It might be worth exploring whether a simpler policy could be created for Fedora more along the lines of Android, which is 100% confined+enforcing these days. This would however almost certainly need to target a specific spin and usage model since Fedora is used in so many different ways by different people. 5) I am curious about how this file got this context in the first place. It would not have been the result of copying or moving the file from another location. Someone running as root with SELinux either permissive or disabled had to have set it explicitly, either via chcon or by adding it incorrectly to file_contexts and then running restorecon. I would guess that someone ran chcon as root with SELinux permissive and mistyped it. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
