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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
