CentUS 7.4
From sealert: SELinux is preventing /usr/sbin/sshd from read access on the file /etc/ssh/moduli.
***** Plugin restorecon (94.8 confidence) suggests ************************
If you want to fix the label. /etc/ssh/moduli default label should be etc_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/ssh/moduli <...> Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:unlabeled_t:s0 Target Objects /etc/ssh/moduli [ file ] Source sshd Source Path /usr/sbin/sshd ---------
Except: ls -laFZ /etc/ssh/moduli -rw-r--r--. root root system:object_r:etc_t:s0 /etc/ssh/moduli
ls -laFZ /usr/sbin/sshd -rwxr-xr-x. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd*
And I even restarted sshd. So, what's selinux seeing that I'm not?
mark
Trevor Hemsley wrote:
On 07/03/18 20:18, m.roth@5-cent.us wrote:
Target Context system_u:object_r:unlabeled_t:s0
That.
Is a useless to me answer. I did the restorecon, and included the ll -Z, and /etc/ssh/moduli is *not* unlabeled any more. And *after* I did the restorecon, I restarted sshd. So what target is unlablelled?
Just to be anal - as I included in the original post, it already *was* etc_t, I just did semanage fcontext -a -t etc_t /etc/ssh/moduli, and then a restorecon -v on it, and nothing was changed. So its label is *already* good.
Is there something *else* that you can suggest that I should restart, that might be caching the label, given that I restarted sshd?
mark
On 03/07/2018 03:18 PM, m.roth@5-cent.us wrote:
CentUS 7.4
From sealert: SELinux is preventing /usr/sbin/sshd from read access on the file /etc/ssh/moduli.
***** Plugin restorecon (94.8 confidence) suggests
If you want to fix the label. /etc/ssh/moduli default label should be etc_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/ssh/moduli <...> Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:unlabeled_t:s0 Target Objects /etc/ssh/moduli [ file ] Source sshd Source Path /usr/sbin/sshd
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.
Is it wrong in your file_contexts configuration? If not, then restorecon -F -v /etc/ssh/moduli should fix (by default, restorecon doesn't touch user identity since it reflects creator and can vary).
ls -laFZ /usr/sbin/sshd -rwxr-xr-x. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd*
And I even restarted sshd. So, what's selinux seeing that I'm not?
mark
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
Stephen Smalley wrote:
On 03/07/2018 03:18 PM, m.roth@5-cent.us wrote:
CentUS 7.4
From sealert: SELinux is preventing /usr/sbin/sshd from read access on the file /etc/ssh/moduli.
***** Plugin restorecon (94.8 confidence) suggests
If you want to fix the label. /etc/ssh/moduli default label should be etc_t. Then you can run restorecon. Do # /sbin/restorecon -v /etc/ssh/moduli <...> Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:unlabeled_t:s0 Target Objects /etc/ssh/moduli [ file ] Source sshd Source Path /usr/sbin/sshd
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.
Is it wrong in your file_contexts configuration? If not, then restorecon -F -v /etc/ssh/moduli should fix (by default, restorecon doesn't touch user identity since it reflects creator and can vary).
Thank you, Stephen. As I see it was happening at least once every half hour, and it hasn't happened since I fixed that, it looks like that was the answer.
mark
On Wednesday, March 7, 2018 2:26:14 PM AKST m.roth@5-cent.us wrote:
Stephen Smalley wrote:
On 03/07/2018 03:18 PM, m.roth@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
justina colmena wrote:
On Wednesday, March 7, 2018 2:26:14 PM AKST m.roth@5-cent.us wrote:
Stephen Smalley wrote:
On 03/07/2018 03:18 PM, m.roth@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?
Sorry, typo. We're currently overwhelmed, due to an environmental incident, and I'm exhausted.
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
Which requires rebooting the system, and for a filesystem of any real size, means waiting for-bloody-ever.
I think it gets system if you copy it without copying the selinux label....
mark
On Thursday, March 8, 2018 2:14:53 PM AKST Thomas Cameron wrote:
On 03/08/2018 05:04 PM, m.roth@5-cent.us wrote:
I think it gets system if you copy it without copying the selinux label....
Pretty sure it inherits from the parent directory if you copy, doesn't it?
So you want a PGP/GPG signature thingy? Now we need a mental health check, because the date, time, subject, and intended recipient(s) are not part of what is actually signed. [/sarcasm]
So if you *copy* (cp) a file, it usually inherits "context" from the destination parent directory.
On the other hand if you *move* (mv) a file, it tends to retain its original security context.
I have also had trouble copying a symlinked file when a deep copy of the data was made, but the basic permissions of the new file were set to 0777, that of the symlink, not the original file pointed to.
These things are not always working the way they are supposed to, and the rules are not always consistent.
On 03/08/2018 04:01 PM, justina colmena wrote:
On Wednesday, March 7, 2018 2:26:14 PM AKST m.roth@5-cent.us wrote:
Stephen Smalley wrote:
On 03/07/2018 03:18 PM, m.roth@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.
selinux@lists.fedoraproject.org
-
justina colmena -
m.roth＠5-cent.us -
Stephen Smalley -
Thomas Cameron -
Trevor Hemsley