Bug 784411

Summary: restorecon uses wrong context for /etc/ssh/ssh_known_hosts or policy wonked
Product: Red Hat Enterprise Linux 6 Reporter: cowan.ml
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: dwalsh, mmalik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 12:30:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description cowan.ml 2012-01-24 19:57:57 UTC
Description of problem:
was trying to remove an old key and ran into this:
---
bad# ssh-keygen -R XXX -f /etc/ssh/ssh_known_hosts
link /etc/ssh/ssh_known_hosts to /etc/ssh/ssh_known_hosts.old: Permission denied
---
and in the logs...
---
Jan 23 16:21:32 XXX kernel: : type=1400 audit(1327353692.321:19991): avc:  denied  { link } for  pid=19831 comm="ssh-keygen" name="ssh_known_hosts" dev=sda2 ino=282651 scontext=unconfined_u:unconfined_r:ssh_keygen_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
---

looking at the file and ssh-keygen...
---
bad# ls -alZ /etc/ssh/ssh_known_hosts `which ssh-keygen`
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   /etc/ssh/ssh_known_hosts
-rwxr-xr-x. root root system_u:object_r:ssh_keygen_exec_t:s0 /usr/bin/ssh-keygen
---

tried restorecon, no change...
---
bad# restorecon /ssh/ssh_known_hosts `which ssh-keygen`
bad# ls -alZ /etc/ssh/ssh_known_hosts `which ssh-keygen`
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   /etc/ssh/ssh_known_hosts
-rwxr-xr-x. root root system_u:object_r:ssh_keygen_exec_t:s0 /usr/bin/ssh-keygen
---

interestingly some almost identical systems weren't having the problem,
looking there...
---
works# ls -alZ /etc/ssh/ssh_known_hosts `which ssh-keygen`
-rw-r--r--. root root unconfined_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_known_hosts
-rwxr-xr-x. root root system_u:object_r:ssh_keygen_exec_t:s0 /usr/bin/ssh-keygen
---

did
---
bad# chcon unconfined_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_known_hosts
---
and then it's happy (no error, and I can remove the old key).

restorecon changes it to the broken state
---
works# restorecon /etc/ssh/ssh_known_hosts
badnow# ls -alZ /etc/ssh/ssh_known_hosts
-rw-------. root root system_u:object_r:etc_t:s0       /etc/ssh/ssh_known_hosts
---
and removing an old key fails


Version-Release number of selected component (if applicable):
policycoreutils-2.0.83-19.8.el6_0.x86_64
selinux-policy-targeted-3.7.19-126.el6_2.4.noarch


How reproducible:
always
I don't know why a few systems *didn't* end up broken,
but I can break them by running restorecon

Steps to Reproduce:
1. run 'restorecon /etc/ssh/ssh_known_hosts'
2. try to remove an old key (ssh -R [system] -f /etc/ssh/ssh_known_hosts)
  
Actual results:
avc denied generated, permission denied error, old key not removed

Expected results:
no avc, no perm error, old key removed

Additional info:

Comment 2 Miroslav Grepl 2012-01-25 07:25:59 UTC
You can try the latest RHEL6 policy from

http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/

-134.el6 packages which make this working again.

Comment 3 Milos Malik 2012-01-25 07:38:31 UTC
Good catch.

# rpm -qa selinux-policy\*
selinux-policy-minimum-3.7.19-126.el6_2.4.noarch
selinux-policy-doc-3.7.19-126.el6_2.4.noarch
selinux-policy-mls-3.7.19-126.el6_2.4.noarch
selinux-policy-targeted-3.7.19-126.el6_2.4.noarch
selinux-policy-3.7.19-126.el6_2.4.noarch
# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
# touch /etc/ssh/ssh_known_hosts
# restorecon -Rv /etc/ssh/
# ssh-keygen -R xxx.redhat.com -f /etc/ssh/ssh_known_hosts
link /etc/ssh/ssh_known_hosts to /etc/ssh/ssh_known_hosts.old: Permission denied
# echo $?
255
# ausearch -m avc -ts recent
----
time->Wed Jan 25 02:32:40 2012
type=SYSCALL msg=audit(1327476760.911:12074): arch=c000003e syscall=86 success=no exit=-13 a0=7f8f1a459b80 a1=7fffc0d9b6f0 a2=2 a3=0 items=0 ppid=12566 pid=12763 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=734 comm="ssh-keygen" exe="/usr/bin/ssh-keygen" subj=unconfined_u:unconfined_r:ssh_keygen_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1327476760.911:12074): avc:  denied  { link } for  pid=12763 comm="ssh-keygen" name="ssh_known_hosts" dev=sdb1 ino=1461765 scontext=unconfined_u:unconfined_r:ssh_keygen_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file
----

Comment 4 cowan.ml 2012-01-25 15:16:17 UTC
The -134 package from comment 2 resolves the problem.

And then using ssh-keygen automagically corrects the context?
nifty, didn't expect that.

---
bad# ls -alZ /etc/ssh/ssh_known_hosts
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   /etc/ssh/ssh_known_hosts

bad# ssh-keygen -R frappe -f /etc/ssh/ssh_known_hosts
link /etc/ssh/ssh_known_hosts to /etc/ssh/ssh_known_hosts.old: Permission denied

bad# yum install http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/selinux-policy-targeted-3.7.19-134.el6.noarch.rpm http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/selinux-policy-3.7.19-134.el6.noarch.rpm
...

stillbad?# ls -alZ /etc/ssh/ssh_known_hosts
-rw-r--r--. root root unconfined_u:object_r:etc_t:s0   /etc/ssh/ssh_known_hosts

works# ssh-keygen -R frappe -f /etc/ssh/ssh_known_hosts
/etc/ssh/ssh_known_hosts updated.
Original contents retained as /etc/ssh/ssh_known_hosts.old

autofixed?# ls -alZ /etc/ssh/ssh_known_hosts
-rw-------. root root unconfined_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_known_hosts
---

Comment 5 Daniel Walsh 2012-01-25 21:20:37 UTC
Fixed in selinux-policy-3.7.19-134.el6

Comment 10 errata-xmlrpc 2012-06-20 12:30:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0780.html