Hide Forgot
Description of problem: # ssh-keygen (creates keys) # ls -Zd .ssh drwx------. root root staff_u:object_r:admin_home_t:SystemLow .ssh # ls -Z .ssh -rw-------. root root staff_u:object_r:admin_home_t:SystemLow id_rsa -rw-r--r--. root root staff_u:object_r:admin_home_t:SystemLow id_rsa.pub # restorecon -RvvF .ssh restorecon reset /root/.ssh context staff_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0 restorecon reset /root/.ssh/id_rsa context staff_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0 restorecon reset /root/.ssh/id_rsa.pub context staff_u:object_r:admin_home_t:s0->system_u:object_r:ssh_home_t:s0 Version-Release number of selected component (if applicable): selinux-policy-mls-3.7.19-70.el6 How reproducible: 100% Steps to Reproduce: 1. ssh-keygen 2. ls -dZ .ssh 3. ls -Z .ssh Actual results: Created .ssh directory and underlying generated files have bad context Expected results: Context correct Additional info: This causes denials for example when adding new entry to known_hosts by ssh command
It looks like we are missing a transition sysadm_t -> sshd_keygen_t -> ssh_keygen_t We have in F15 policy --- ######################################## # # ssh_keygen local policy # # ssh_keygen_t is the type of the ssh-keygen program when run at install time # and by sysadm_t manage_dirs_pattern(ssh_keygen_t, ssh_home_t, ssh_home_t) manage_files_pattern(ssh_keygen_t, ssh_home_t, ssh_home_t) userdom_admin_home_dir_filetrans(ssh_keygen_t, ssh_home_t, dir) ---
Mirek, could you add the following rule userdom_admin_home_dir_filetrans(ssh_keygen_t, ssh_home_t, dir) to the local test policy which we created and test whether it works for you.
Yes it resolved the last problem with .ssh directory context: # ls -Zd .ssh drwx------. root root staff_u:object_r:ssh_home_t:SystemLow .ssh # ls -Z .ssh -rw-------. root root staff_u:object_r:ssh_home_t:SystemLow id_rsa -rw-r--r--. root root staff_u:object_r:ssh_home_t:SystemLow id_rsa.pub Just for the record my custom policy: policy_module(keygen,1.2) require{ type admin_home_t; type ssh_keygen_t; type ssh_keygen_exec_t; type sysadm_t; type ssh_home_t; role sysadm_r; } domtrans_pattern(sysadm_t, ssh_keygen_exec_t, ssh_keygen_t) userdom_admin_home_dir_filetrans(ssh_keygen_t, ssh_home_t, dir) term_use_all_ptys(ssh_keygen_t) role sysadm_r types ssh_keygen_t; allow ssh_keygen_t admin_home_t:dir search;
Mirku, I added a fix to the latest RHLE6 policy (-77 release) so you can test it then with this release without the local policy.
I tested with the latest selinux-policy and it doesn't resolve the issue for me, the .ssh folder cannot be created: # rpm -q selinux-policy-mls selinux-policy-mls-3.7.19-78.el6.noarch ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Could not create directory '/root/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: open /root/.ssh/id_rsa failed: No such file or directory. Saving the key failed: /root/.ssh/id_rsa.
Strange, I thought it was working with a local policy moodule. Any AVC msgs?
Per discussion on IRC, adding this custom moduole resolves the issue: module mypol 1.0; require { type ssh_keygen_t; type secadm_screen_t; class capability dac_override; } #============= secadm_screen_t ============== allow secadm_screen_t self:capability dac_override; #============= ssh_keygen_t ============== allow ssh_keygen_t self:capability dac_override;
Ups, please ignore the screen part :)
Strange, I am just trying to reproduce it, but it is working for me. Milos, could you try to test it?
Doesn't work for me either. I could reproduce the bug on -74 policy. With -78 policy there are two cases: 1. ssh-keygen executed in the console - root:sysadm_r:sysadm_t:s0-s15:c0.c1023 - ssh-keygen doesn't work at all - no AVC but following AVC appears after semodule -DB time->Mon Mar 14 11:59:30 2011 type=SYSCALL msg=audit(1300100370.953:92): arch=40000003 syscall=11 success=yes exit=0 a0=865dd58 a1=865e890 a2=864bf78 a3=865e890 items=0 ppid=1289 pid=1567 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ssh-keygen" exe="/usr/bin/ssh-keygen" subj=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1300100370.953:92): avc: denied { noatsecure } for pid=1567 comm="ssh-keygen" scontext=root:sysadm_r:sysadm_t:s0-s15:c0.c1023 tcontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tclass=process type=AVC msg=audit(1300100370.953:92): avc: denied { siginh } for pid=1567 comm="ssh-keygen" scontext=root:sysadm_r:sysadm_t:s0-s15:c0.c1023 tcontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tclass=process type=AVC msg=audit(1300100370.953:92): avc: denied { rlimitinh } for pid=1567 comm="ssh-keygen" scontext=root:sysadm_r:sysadm_t:s0-s15:c0.c1023 tcontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tclass=process type=AVC msg=audit(1300100370.953:92): avc: denied { read write } for pid=1567 comm="ssh-keygen" path="/dev/tty1" dev=devtmpfs ino=5069 scontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tcontext=root:object_r:user_tty_device_t:s0 tclass=chr_file type=AVC msg=audit(1300100370.953:92): avc: denied { read write } for pid=1567 comm="ssh-keygen" path="/dev/tty1" dev=devtmpfs ino=5069 scontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tcontext=root:object_r:user_tty_device_t:s0 tclass=chr_file type=AVC msg=audit(1300100370.953:92): avc: denied { read write } for pid=1567 comm="ssh-keygen" path="/dev/tty1" dev=devtmpfs ino=5069 scontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tcontext=root:object_r:user_tty_device_t:s0 tclass=chr_file type=AVC msg=audit(1300100370.953:92): avc: denied { read write } for pid=1567 comm="ssh-keygen" name="tty1" dev=devtmpfs ino=5069 scontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tcontext=root:object_r:user_tty_device_t:s0 tclass=chr_file 2. ssh-keygen executed in ssh terminal (connected as root + switched to sysadm_r role) - root:sysadm_r:sysadm_t:s0-s15:c0.c1023 - ssh-keygen starts, bug failes lateron with open /root/.ssh/id_rsa failed: No such file or directory. Saving the key failed: /root/.ssh/id_rsa. ---- time->Mon Mar 14 11:54:23 2011 type=SYSCALL msg=audit(1300100063.050:45): arch=40000003 syscall=39 success=no exit=-13 a0=bfac83cc a1=1c0 a2=147b5c a3=bfac83cc items=0 ppid=1336 pid=1490 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ssh-keygen" exe="/usr/bin/ssh-keygen" subj=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1300100063.050:45): avc: denied { dac_override } for pid=1490 comm="ssh-keygen" capability=1 scontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tcontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tclass=capability openssh-5.3p1-39.el6.i686
After loading the module from #c8 ssh-keygen works properly in the ssh session (context root:object_r:ssh_home_t:s0 .ssh) but still not working in the console.
Ok, could you try to turn on the allow_daemons_use_tty boolean? Does it work in the console then?
That boolean brought the console scenario to the same level as the ssh one. Custom module is still required, otherwise I get: type=AVC msg=audit(1300103392.125:216): avc: denied { dac_override } for pid=1891 comm="ssh-keygen" capability=1 scontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tcontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tclass=capability type=SYSCALL msg=audit(1300103392.125:216): arch=40000003 syscall=39 success=yes exit=0 a0=bfc8556c a1=1c0 a2=379b5c a3=bfc8556c items=2 ppid=1289 pid=1891 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=1 comm="ssh-keygen" exe="/usr/bin/ssh-keygen" subj=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 key=(null) type=CWD msg=audit(1300103392.125:216): cwd="/root" type=PATH msg=audit(1300103392.125:216): item=0 name="/root/" inode=19 dev=fc:01 mode=040550 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:admin_home_t:s0 type=PATH msg=audit(1300103392.125:216): item=1 name="/root/.ssh" inode=16050 dev=fc:01 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:ssh_home_t:s0
Why would a root process need dac_override to write to the /root directory? ls -ld /root
Yes, I do not understand also.
modes are in the syscall record. /root is 550 /root/.ssh is 700
Why is root not allowed to write to /root? Is the standard protection on tis dir?
reproduced again on fresh RHEL6.1-20110311.3 with selinux-policy-3.7.19-78.el6 [root@rhel6-64 ~]# id -Z root:sysadm_r:sysadm_t:s0-s15:c0.c1023 [root@rhel6-64 ~]# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Could not create directory '/root/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: open /root/.ssh/id_rsa failed: No such file or directory. Saving the key failed: /root/.ssh/id_rsa. [root@rhel6-64 ~]# ls -ld /root dr-xr-x---. 3 root root 4096 Mar 15 11:29 /root [root@rhel6-64 ~]# ls -Zd /root dr-xr-x---. root root system_u:object_r:admin_home_t:s0 /root [root@rhel6-64 ~]# mkdir /root/mydir [root@rhel6-64 ~]# ls -ld /root/mydir drwxr-xr-x. 2 root root 4096 Mar 15 11:39 /root/mydir [root@rhel6-64 ~]# ls -Zd /root/mydir drwxr-xr-x. root root root:object_r:admin_home_t:s0 /root/mydir type=AVC msg=audit(1300184854.426:46): avc: denied { dac_override } for pid=1373 comm="ssh-keygen" capability=1 scontext=root:sysadm_r:ssh_keygen_t:s0-ss0-s15:c0.c1023 tcontext=root:sysadm_r:ssh_keygen_t:s0-s15:c0.c1023 tclass=capapability type=SYSCALL msg=audit(1300184854.426:46): arch=c000003e syscall=83 success=no exit=-13 a0=7fff8b46b910 a1=1c0 a2=ffffffffffffff88 a3=fffffffc items=0 ppid=1318 pid=1373 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=1 comm="ssh-keygen" exe="/usr/bin/ssh-keygen" subj=root:sysadm_r:ssh :ssh_keygen_t:s0-s15:c0.c1023 key=(null)
So we either change the permissions on the /root directory to 0750 or we add dac_override? If /root has to be 0550 we have no choice.
Adding dac_override would be the answer. Shame that capabilities can't be paired with a target type. For example, dac_override on admin_home_t to limit the scope.
Miroslav lets add it.
Why is dac_override the answer? Why is /root not writable by root?
To protect against root processes that have no capabilities.
Fixed in selinux-policy-3.7.19-79.el6
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0526.html