On 02/09/2015 11:14 AM, James B. Byrne wrote:
> So, I decided to run restorecon -v to
> presumably set the SELinux user correctly for the new keys: But that
> is not what happened:
>
> restorecon -v *
>
> restorecon reset /etc/ssh/ssh_host_rsa_key_4096 context
> unconfined_u:object_r:sshd_key_t:s0->unconfined_u:object_r:etc_t:s0
>
> restorecon reset /etc/ssh/ssh_host_rsa_key_4096.pub context
> unconfined_u:object_r:sshd_key_t:s0->unconfined_u:object_r:etc_t:s0
>
> As you can see, not only did the user not get set to system_u but the
> type was changed to etc_t.
>
> Why were the new key files changed from sshd_key_t types to the
> generic etc_t types? Why was the user not changed in either case from
> unconfined_u to system_u or vice versa?
>
> There is no REQUIREMENT that a host key have a particular file name is
> there? The sshd_config provides for setting one explicitly and doing
> so seems to cause no problems with ssh connections that I have yet
> encountered.
The "system_u" vs. "unconfined_u" is inconsequential. That just comes
from process that set the label.
Looking at the file labeling rules, only the 7 specific file names
get a type of "sshd_key_t", and, strangely, not the /etc/ssh directory
itself, so /restorecon/ will just make any other file there inherit
the type of the directory, which is "etc_t". At first glance that looks
like a bug, but perhaps there is come reason for that.
Ask about it on the selinux list at lists.fedoraproject.org.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.