Bug 486397 - Access to authorized_keys denied when ssh-copy-id is used
Access to authorized_keys denied when ssh-copy-id is used
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-19 11:11 EST by Evan McNabb
Modified: 2011-11-23 11:25 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-23 11:25:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Evan McNabb 2009-02-19 11:11:22 EST
Description of problem:

If I use ssh-copy-id to configure the authorized_keys file on a remote system, the key doesn't work until the context is corrected. This only seems to happen for the root user - normal users are not affected. "restorecon -v /root/.ssh/authorized_keys" solves the problem.

I'm not sure if this is a problem with SELinux or if the script isn't setting the context correctly (if it's the script, we may want to reassign it).

====================
host1:
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@host2
# ssh root@host2

host2:
# tail messages
Feb 18 18:06:03 dhcp243-30 setroubleshoot: SELinux is preventing the sshd from using potentially mislabeled files (authorized_keys). For complete SELinux messages. run sealert -l 4d4d2a21-def3-499d-8c45-582a6ac7cbee

# sealert -l 4d4d2a21-def3-499d-8c45-582a6ac7cbee

Summary:

SELinux is preventing the sshd from using potentially mislabeled files
(authorized_keys).

Detailed Description:

SELinux has denied sshd access to potentially mislabeled file(s)
(authorized_keys). This means that SELinux will not allow sshd to use these
files. It is common for users to edit files in their home directory or tmp
directories and then move (mv) them to system directories. The problem is that
the files end up with the wrong file context which confined applications are not
allowed to access.

Allowing Access:

If you want sshd to access this files, you need to relabel them using restorecon
-v 'authorized_keys'. You might want to relabel the entire directory using
restorecon -R -v ''.

Additional Information:

Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:admin_home_t:s0
Target Objects                authorized_keys [ file ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          <Unknown>
Host                          host2
Source RPM Packages           openssh-server-5.1p1-7.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.6-5.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   home_tmp_bad_labels
Host Name                     host2
Platform                      Linux host2
                              2.6.29-0.131.rc5.git2.fc11.x86_64 #1 SMP Wed Feb
                              18 19:24:47 EST 2009 x86_64 x86_64
Alert Count                   2
First Seen                    Mon Feb 18 18:05:58 2041
Last Seen                     Mon Feb 18 18:05:58 2041
Local ID                      4d4d2a21-def3-499d-8c45-582a6ac7cbee
Line Numbers                  

Raw Audit Messages    

node=host2 type=AVC msg=audit(2244841558.584:49): avc:  denied  { read } for  pid=3250 comm="sshd" name="authorized_keys" dev=dm-0 ino=170 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

node=host2 type=SYSCALL msg=audit(2244841558.584:49): arch=c000003e syscall=2 success=no exit=-13 a0=1bbcdf0 a1=800 a2=1 a3=7f55aa3197b0 items=0 ppid=2909 pid=3250 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
====================

Version-Release number of selected component (if applicable):

Rawhide 20090219
selinux-policy-3.6.6-5.fc11

How reproducible:
Every time

Steps to Reproduce:
1. see above
  
Actual results:
Password still required

Expected results:
No password required

Additional info:
Comment 1 Daniel Walsh 2009-02-20 10:54:08 EST
Does restorecon -R -v /root 

change the context on these files?
Comment 2 Evan McNabb 2009-02-23 10:02:09 EST
Yes, running "restorecon -R -v /root" sets the correct context and root can then log in automatically.
Comment 3 Daniel Walsh 2009-02-23 11:31:22 EST
We probably need to add /root/.ssh to restorecond.
Comment 4 Daniel Walsh 2009-02-23 11:34:36 EST
Fixed in policycoreutils-2.0.62-2.fc11
Comment 5 nico-redhat-bugzilla 2011-04-02 04:17:01 EDT
I am experiencing exactly this bug again in Fedora 14. ssh-copy-id root@fedorabox generates exactly the described errors. Interestingly after fixing it with restorecon it came up after reboot again.

This is a fresh Fedora 14 installation.
Comment 6 Christian Kujau 2011-08-06 21:24:09 EDT
This happened before in #499343 and #512830 (F11) and apparently keeps popping up. F15 has the same issue.

While I can understand that newly created files have to be labelled correctly, I somehow think this should be done automagically. I.e. the user should not have to relabel her files manually. Isn't it possible to somhow inherit SELinux labels, so that ~/.ssh/authorized_keys has the same labels as $HOME?
Comment 7 Daniel Walsh 2011-08-10 13:15:41 EDT
Yes but this is not something we want.  For example we want to only allow root apps like sshd to read ~/.ssh/authorized_keys  But not read ~/creditcard.txt

In F16, we have new code that should label .ssh correctly when it gets created in a homedir without the user needing to relabel it.
Comment 8 Daniel Walsh 2011-11-18 14:37:15 EST
Christian we are trying to prevent sshd from reading every file with the users homedir.  The way we do this is to label ~/.ssh/* differently then the rest of the directory.  So sshd can read the .ssh directory but not the rest.  In F16 now, we actually can catch the user typeing mkdir ~/.ssh and have the proper labeling happen. Before this, the user was responsible for making sure the label was correct.  BTW the user is also responsible to make sure the ownership and permission flags are correct also.

ssh-copy-id is a problem since it does this for the user, and for a while had the restorecon built in. Now we are asking that it get put back in.
Comment 9 Christian Kujau 2011-11-20 02:45:58 EST
Thanks for replying, Daniel. I understand that proper labelling is paramount for SELinux to function in a secure manner. I was merely stating the obvious, that it's a user-noticable barrier. I'm glad that F16 takes care of the labelling now, as soon as I get my hands on a F16 system I'll try for myself. Thanks again!
Comment 10 Daniel Walsh 2011-11-23 11:25:18 EST
There was a bug in ssh-copy-id that has just been fixed, where it will now execute restorecon when it is run.

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