Bug 499343 - SELinux prevents sshd from reading authorized_keys file and allowing private key authentication
Summary: SELinux prevents sshd from reading authorized_keys file and allowing private ...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2009-05-06 09:29 UTC by Oded Arbel
Modified: 2009-05-06 12:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-05-06 11:43:43 UTC
Type: ---

Attachments (Terms of Use)

Description Oded Arbel 2009-05-06 09:29:05 UTC
Description of problem:
When trying to log in using SSH to a Fedora computer, sshd need to read the local authorized_keys file in order to allow private key (passwordless) authentication. SELinux's targeted policy prevents sshd from reading the file and hence from allowing passwordless logins

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

How reproducible:

Steps to Reproduce:
1. enable SELinux tageted policy
2. copy the public key of some user into the ~/.ssh/authorized_keys file of another user
3. ssh from the first user's account to the second user's login
Actual results:
SSH asks for a password

Expected results:
SSH should allow the user to log in without requiring a password

Additional info:
setroubleshoot reports as thus:
SELinux is preventing sshd (sshd_t) "read" home_root_t. 

Detailed Description
SELinux denied access requested by sshd. It is not expected that this access is required by sshd and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. 

Allowing Access
You can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. 

Additional Information
Source Context:  system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context:  unconfined_u:object_r:home_root_t:s0
Target Objects:  authorized_keys [ file ]
Source:  sshd
Source Path:  /usr/sbin/sshd
Port:  <Unknown>
Host:  chen.office.taboola.com
Source RPM Packages:  openssh-server-5.2p1-2.fc11
Target RPM Packages:  
Policy RPM:  selinux-policy-3.6.12-28.fc11
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  catchall
Host Name:  chen.office.taboola.com
Platform:  Linux chen.office.taboola.com #1 SMP Fri Apr 24 10:57:09 EDT 2009 x86_64 x86_64
Alert Count:  46
First Seen:  Tue 31 Mar 2009 12:09:48 PM IDT
Last Seen:  Wed 06 May 2009 11:57:22 AM IDT
Local ID:  676f5d5d-2d60-425a-88fd-3375cd96cfb7
Line Numbers:  
Raw Audit Messages :
node=chen.office.taboola.com type=AVC msg=audit(1241600242.790:104): avc: denied { read } for pid=10458 comm="sshd" name="authorized_keys" dev=dm-1 ino=845588 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file node=chen.office.taboola.com type=SYSCALL msg=audit(1241600242.790:104): arch=c000003e syscall=2 success=no exit=-13 a0=7fec9b791620 a1=800 a2=1 a3=4000 items=0 ppid=1573 pid=10458 auid=4294967295 uid=0 gid=0 euid=16777216 suid=0 fsuid=16777216 egid=16777216 sgid=0 fsgid=16777216 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Comment 1 Daniel Walsh 2009-05-06 11:43:43 UTC
This home directory is badly labeled.

restorecon -R -v /home

Or where ever the home directory is located.

home_root_t is the label of the /home directory 

Individual directories under /home should be labeled user_home_dir_t

The .ssh directory should be labeled user_ssh_home_t

Comment 2 Oded Arbel 2009-05-06 12:16:01 UTC
When a new user creates a .ssh directory (for example - using ssh-keygen) - what causes the labeling of the new directory?

Comment 3 Daniel Walsh 2009-05-06 12:40:04 UTC
The problem here is the whole directory is mislabeled.  If the whole directory was labeled incorrectly, I have no idea why.

But a user running ssh-keygen in a directory labeled user_home_dir_t will probably not create the directory with the correct label.  If you were running restorcond service, it would probably have labeled it correctly.  We are working on solutions for users creating random files directories in the homedir and making sure they are labeled correctly.

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