RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 989714 - SELinux User Context for /root/.ssh/ incorrect after restorecon
Summary: SELinux User Context for /root/.ssh/ incorrect after restorecon
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.4
Hardware: x86_64
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-29 18:44 UTC by Ryan Foster
Modified: 2013-07-29 19:31 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-29 19:09:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Ryan Foster 2013-07-29 18:44:06 UTC 
Description of problem:
On RHEL 6.4 x86_64, running "restorecon -r -v /root/.ssh/" only changes the Type  Context for the files within /root/.ssh/ and not their User Context.


How reproducible:
This is reproducible every time for me.


Steps to Reproduce:
1.  Login as root.

2.  Make a directory for SSH in /root/
[root@rhel ~]# mkdir /root/.ssh/

3.  Place an appropriate public key in /root/.ssh/authorized_keys using any regular file transfer method (SFTP/SCP).  I used WinSCP using.

4.  Check SELinux context on /root/.ssh/
[root@rhel ~]# ls -alZ /root/.ssh/
drwx------. root root unconfined_u:object_r:admin_home_t:s0 .
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 ..
-rw-------. root root unconfined_u:object_r:admin_home_t:s0 authorized_keys

5.  Run restorecon on /root/.ssh/
[root@rhel ~]# restorecon -r -v /root/.ssh/
restorecon reset /root/.ssh context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /root/.ssh/authorized_keys context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:ssh_home_t:s0

6.  Check SELinux context on /root/.ssh/
[root@rhel ~]# ls -alZ
drwx------. root root unconfined_u:object_r:ssh_home_t:s0 .
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 ..
-rw-------. root root unconfined_u:object_r:ssh_home_t:s0 authorized_keys


Actual results:
/root/.ssh/ and /root/.ssh/authorized_keys keep the User Context "unconfined_u".


Expected results:
/root/.ssh/ and /root/.ssh/authorized_keys change to the User Context "system_u".


Additional info:
This is similar to bug 752197, except without ssh-copy-id.  Though, in that bug's description, restorecon changes the User Context to "system_u" for /root/.ssh/ and /root/.ssh/authorized_keys.  I was expecting the User Context to change based on that bug description and this SELinux rule:

/root/\.ssh(/.*)?       system_u:object_r:ssh_home_t:s0

I've seen some sources[1][2][3][4] say that for the most part SELinux users and roles can be ignored.  In this case, SSH keys certainly work after the restorecon in Step 5, despite /root/.ssh/ and /root/.ssh/authorized_keys having User Context "unconfined_u".  Still, since the expected and actual behaviors differed, I felt filing a bug report might provide some clarity on whether or not this is actually a bug.

  [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html
"Note" at the bottom
  [2] https://docs.fedoraproject.org/en-US/Fedora/12/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html
"Note" at the bottom (noted for having the same text as [1])
  [3] https://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/sect-Security-Enhanced_Linux-Working_with_SELinux-Mounting_File_Systems.html
Last paragraph
  [4] http://www.centos.org/docs/5/html/Deployment_Guide-en-US/rhlcommon-chapter-0017.html#sec-sel-file-relabel
"Tip" section near the top of linked section
Comment 2 Daniel Walsh 2013-07-29 19:09:10 UTC 
We don't change the user context by default

restorecon -F -Rv /root/.ssh

Should get you what you want.
Comment 3 Ryan Foster 2013-07-29 19:31:15 UTC 
(In reply to Daniel Walsh from comment #2)
> We don't change the user context by default
> 
> restorecon -F -Rv /root/.ssh
> 
> Should get you what you want.

Ah-hah.  That does indeed change the User Context.  I'm glad to finally understand that.  Going back and rereading "man restorecon", I noticed these lines:

"man restorecon" excerpts:
"This program is primarily used to reset the security context (type)
(extended attributes) on one or more files."
"If a file object has a context, restorecon will only modify the type portion of the security context.  The -F option will force a replacement of the entire context."

If I'd read it a little more closely, I could have saved you the trouble.  Sorry about that.

Thanks for responding!
Note You need to log in before you can comment on or make changes to this bug.