On 03/08/2018 04:01 PM, justina colmena wrote:
On Wednesday, March 7, 2018 2:26:14 PM AKST m.roth(a)5-cent.us wrote:
> Stephen Smalley wrote:
>
>> On 03/07/2018 03:18 PM, m.roth(a)5-cent.us 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.