Bug 692828

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