2:18 p.m.
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
3:35 p.m.
Trevor Hemsley wrote:
On 07/03/18 20:18, m.roth(a)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
3:47 p.m.
New subject: [Non-DoD Source] An selinux issue
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.
***** 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(a)lists.fedoraproject.org
To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
5:26 p.m.
New subject: [Non-DoD Source] An selinux issue
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.
>
> ***** 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
3:01 p.m.
New subject: [Non-DoD Source] An selinux issue
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
5:04 p.m.
New subject: [Non-DoD Source] An selinux issue
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?
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
5:38 p.m.
New subject: [Non-DoD Source] An selinux issue
On Thursday, March 8, 2018 2:14:53 PM AKST Thomas Cameron wrote:
On 03/08/2018 05:04 PM, m.roth(a)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.
9:11 a.m.
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.
2237
days inactive
2239
days old
selinux@lists.fedoraproject.org
9 comments
5 participants
participants (5)
-
justina colmena -
m.roth＠5-cent.us -
Stephen Smalley -
Thomas Cameron -
Trevor Hemsley