I generated a new host key for one of our systems using: ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key_4096 I then ran 'ls -Z on the keys' ll -Z *key* -rw-------. root root system_u:object_r:sshd_key_t:s0 ssh_host_dsa_key -rw-r--r--. root root system_u:object_r:sshd_key_t:s0 ssh_host_dsa_key.pub -rw-------. root root system_u:object_r:sshd_key_t:s0 ssh_host_key -rw-r--r--. root root system_u:object_r:sshd_key_t:s0 ssh_host_key.pub -rw-------. root root system_u:object_r:sshd_key_t:s0 ssh_host_rsa_key -rw-------. root root unconfined_u:object_r:sshd_key_t:s0 ssh_host_rsa_key_4096 -rw-r--r--. root root unconfined_u:object_r:sshd_key_t:s0 ssh_host_rsa_key_4096.pub -rw-r--r--. root root system_u:object_r:sshd_key_t:s0 ssh_host_rsa_key.pub As it seems odd, to me, that all the other files had a system_u user while the new had unconfined_u. 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. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
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.
> On Feb 9, 2015, at 12:27 PM, Robert Nichols <rnicholsNOSPAM at comcast.net> wrote: > > On 02/09/2015 11:14 AM, James B. Byrne wrote: >> So, I decided to run restorecon -v to >>...>> 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 >>...>> 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.If you want to use a non-default filename for something, so that the pre-defined regexes which restorecon uses won?t match on it, you can either add a new regex to the policy which will be persistent or just use chcon to set the type manually. ? Mark Tinberg mark.tinberg at wisc.edu