Hide Forgot
Description of problem: The example below is for staff_u user, the same applies for user_u user. # id # ssh-keygen (creates keys) # ls -Zd .ssh drwx------. sshstaff sshstaff staff_u:object_r:user_home_t:SystemLow .ssh/ # ls -Z .ssh -rw-------. sshstaff sshstaff staff_u:object_r:user_home_t:SystemLow id_rsa -rw-r--r--. sshstaff sshstaff staff_u:object_r:user_home_t:SystemLow id_rsa.pub # restorecon -RvvF .ssh restorecon reset /home/sshstaff/.ssh context staff_u:object_r:user_home_t:s0->staff_u:object_r:ssh_home_t:s0 restorecon reset /home/sshstaff/.ssh/id_rsa context staff_u:object_r:user_home_t:s0->staff_u:object_r:ssh_home_t:s0 restorecon reset /home/sshstaff/.ssh/id_rsa.pub context staff_u:object_r:user_home_t:s0->staff_u:object_r:ssh_home_t:s0 Version-Release number of selected component (if applicable): selinux-policy-mls-3.7.19-80.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. This is the same issue as Bug 682974
Adding ~/.ssh/* to /etc/selinux/restorecond_user.conf fixes this issue. This should be added to the defaults I think.
I don't know why but after few login attempts the context of ~/.ssh/* now doesn't change to ssh_home_t. Looks like I the comment #1 is bogus. So please ignore it.
restorecond would discover this mislabel and fix the directory without adding .ssh/* to the conf. I think we should add ssh_run_keygen(sysadm_r, sysadm_r) to get the label correct in the first place. I think this fix can wait for 6.2, or get it in 6.1 if we have time.
Mirek, could you try to test it with the following local policy # cat mykeygen.te policy_module(mykeygen, 1.0) require{ type staff_t; role staff_r; } ssh_run_keygen(staff_t, staff_r) and # make -f /usr/share/selinux/devel/include/Makefile # semodule -i mykeygen.pp
I tried the above module, but now ssh-keygen cannot create .ssh directory and underlying files. I see these denials in audit.log (after enabling noaudit rules): type=AVC msg=audit(1301886542.606:2181): avc: denied { rlimitinh } for pid=28126 comm="ssh-keygen" scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:ssh_keygen_t:s0 tclass=process type=AVC msg=audit(1301886542.606:2181): avc: denied { siginh } for pid=28126 comm="ssh-keygen" scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:ssh_keygen_t:s0 tclass=process type=AVC msg=audit(1301886542.606:2181): avc: denied { noatsecure } for pid=28126 comm="ssh-keygen" scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:ssh_keygen_t:s0 tclass=process type=AVC msg=audit(1301886546.933:2182): avc: denied { search } for pid=28126 comm="ssh-keygen" name="/" dev=dm-3 ino=2 scontext=staff_u:staff_r:ssh_keygen_t:s0 tcontext=system_u:object_r:home_root_t:s0-s15:c0.c1023 tclass=dir type=AVC msg=audit(1301886546.933:2183): avc: denied { search } for pid=28126 comm="ssh-keygen" name="/" dev=dm-3 ino=2 scontext=staff_u:staff_r:ssh_keygen_t:s0 tcontext=system_u:object_r:home_root_t:s0-s15:c0.c1023 tclass=dir And also the above module doesn't count user_u user in, where the behavior remains the same. Please note that this seems similar to bug 692457 reported for root/sysadm_r
We already have ssh_run_keygen(sysadm_r, sysadm_r) in policy. And we have userdom_search_admin_dir(ssh_keygen_t) So try to test it with files_search_home(ssh_keygen_t) in the local policy.
For the staff_u user the problems are solved using this custom module: # cat mykeygen.te policy_module(mykeygen, 1.3) require{ type staff_t; type ssh_home_t; type ssh_keygen_t; role staff_r; } ssh_run_keygen(staff_t, staff_r) userdom_search_user_home_dirs(ssh_keygen_t) userdom_user_home_dir_filetrans(ssh_keygen_t, ssh_home_t, dir) now back to the problem to the user_u user. Should be enough to s/staff/user in the above module?
Ok, user_u works also when added another ssh_run_keygen macro for user_u. The final custom module that solves all the issues is: ----- # cat mykeygen.te policy_module(mykeygen, 1.4) require{ type staff_t; type user_t; type ssh_home_t; type ssh_keygen_t; role staff_r; role user_r; } ssh_run_keygen(user_t, user_r) ssh_run_keygen(staff_t, staff_r) userdom_search_user_home_dirs(ssh_keygen_t) userdom_user_home_dir_filetrans(ssh_keygen_t, ssh_home_t, dir) ----- Thanks for the help Mirek!
Miroslav lets add ssh_run_keygen($3,$2) to ssh_role_template
Fixed in selinux-policy-3.7.19-81.el6
Under staff_u ssh-keygen does not work at all. $ rpm -qa selinux-policy\* selinux-policy-targeted-3.7.19-81.el6.noarch selinux-policy-doc-3.7.19-81.el6.noarch selinux-policy-minimum-3.7.19-81.el6.noarch selinux-policy-mls-3.7.19-81.el6.noarch selinux-policy-3.7.19-81.el6.noarch $ sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: mls $ id uid=503(sshstaff) gid=504(sshstaff) groups=504(sshstaff) context=staff_u:staff_r:staff_t:s0 $ ssh-keygen $ echo $? 1 $
I had to disable dontaudit rules first to see what's going on: # ausearch -m avc -m user_avc -ts today -i | grep staff_u type=SYSCALL msg=audit(04/06/2011 04:30:58.407:11816) : arch=i386 syscall=execve success=yes exit=0 a0=8f17640 a1=bf88eaac a2=8f24768 a3=bf88eaac items=0 ppid=2798 pid=2808 auid=sshstaff uid=sshstaff gid=sshstaff euid=sshstaff suid=sshstaff fsuid=sshstaff egid=sshstaff sgid=sshstaff fsgid=sshstaff tty=ttyS0 ses=12 comm=bash exe=/bin/bash subj=staff_u:staff_r:staff_t:s0 key=(null) type=AVC msg=audit(04/06/2011 04:30:58.407:11816) : avc: denied { noatsecure } for pid=2808 comm=bash scontext=system_u:system_r:local_login_t:s0-s15:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0 tclass=process type=AVC msg=audit(04/06/2011 04:30:58.407:11816) : avc: denied { siginh } for pid=2808 comm=bash scontext=system_u:system_r:local_login_t:s0-s15:c0.c1023 tcontext=staff_u:staff_r:staff_t:s0 tclass=process type=SYSCALL msg=audit(04/06/2011 04:31:16.117:11817) : arch=i386 syscall=execve success=yes exit=0 a0=9bbd0e8 a1=9bc0498 a2=9bc45a0 a3=9bc0498 items=0 ppid=2808 pid=2834 auid=sshstaff uid=sshstaff gid=sshstaff euid=sshstaff suid=sshstaff fsuid=sshstaff egid=sshstaff sgid=sshstaff fsgid=sshstaff tty=(none) ses=12 comm=ssh-keygen exe=/usr/bin/ssh-keygen subj=staff_u:staff_r:ssh_keygen_t:s0 key=(null) type=AVC msg=audit(04/06/2011 04:31:16.117:11817) : avc: denied { noatsecure } for pid=2834 comm=ssh-keygen scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:ssh_keygen_t:s0 tclass=process type=AVC msg=audit(04/06/2011 04:31:16.117:11817) : avc: denied { siginh } for pid=2834 comm=ssh-keygen scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:ssh_keygen_t:s0 tclass=process type=AVC msg=audit(04/06/2011 04:31:16.117:11817) : avc: denied { rlimitinh } for pid=2834 comm=ssh-keygen scontext=staff_u:staff_r:staff_t:s0 tcontext=staff_u:staff_r:ssh_keygen_t:s0 tclass=process type=AVC msg=audit(04/06/2011 04:31:16.117:11817) : avc: denied { read write } for pid=2834 comm=ssh-keygen path=/dev/ttyS0 dev=devtmpfs ino=5225 scontext=staff_u:staff_r:ssh_keygen_t:s0 tcontext=staff_u:object_r:user_tty_device_t:s0 tclass=chr_file type=AVC msg=audit(04/06/2011 04:31:16.117:11817) : avc: denied { read write } for pid=2834 comm=ssh-keygen path=/dev/ttyS0 dev=devtmpfs ino=5225 scontext=staff_u:staff_r:ssh_keygen_t:s0 tcontext=staff_u:object_r:user_tty_device_t:s0 tclass=chr_file type=AVC msg=audit(04/06/2011 04:31:16.117:11817) : avc: denied { read write } for pid=2834 comm=ssh-keygen path=/dev/ttyS0 dev=devtmpfs ino=5225 scontext=staff_u:staff_r:ssh_keygen_t:s0 tcontext=staff_u:object_r:user_tty_device_t:s0 tclass=chr_file type=AVC msg=audit(04/06/2011 04:31:16.117:11817) : avc: denied { read write } for pid=2834 comm=ssh-keygen name=ttyS0 dev=devtmpfs ino=5225 scontext=staff_u:staff_r:ssh_keygen_t:s0 tcontext=staff_u:object_r:user_tty_device_t:s0 tclass=chr_file #
Well, this is a new issue which I am fixing.
Fixed in selinux-policy-3.7.19-82.el6
Miroslav did you put this transition into the ssh_role_template?
Yes, I did. optional_policy(` ssh_run_keygen($3,$2) ') This is a strange. It works for staff_t but not for user_t. I will look at it tomorrow.
Ok, I have found a bug in unprivuser.te ifndef(`distro_redhat',` optional_policy(` spamassassin_role(user_r, user_t) ') optional_policy(` ssh_role_template(user, user_r, user_t) ') ... ... ')
Yes we should uncomment that one.
Maybe grab the version from F15.
Fixed in selinux-policy-3.7.19-84.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