692828 – MLS: under staff_u and user_u user ssh-keygen creates .ssh and underlying files with bad context

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 692828 - MLS: under staff_u and user_u user ssh-keygen creates .ssh and underlying files with bad context

Summary: MLS: under staff_u and user_u user ssh-keygen creates .ssh and underlying fil...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	selinux-policy
Sub Component:
Version:	6.1
Hardware:	All
OS:	Linux
Priority:	high
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Miroslav Grepl
QA Contact:	Milos Malik
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	RHEL62CCC 682670 846801 846802
TreeView+	depends on / blocked

Reported:	2011-04-01 10:25 UTC by Miroslav Vadkerti
Modified:	2012-08-08 18:29 UTC (History)
CC List:	4 users (show)
Fixed In Version:	selinux-policy-3.7.19-84.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-05-19 12:27:26 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2011:0526	0	normal	SHIPPED_LIVE	selinux-policy bug fix and enhancement update	2011-05-19 09:37:41 UTC

Description Miroslav Vadkerti 2011-04-01 10:25:41 UTC

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

Comment 1 Miroslav Vadkerti 2011-04-01 10:48:21 UTC

Adding ~/.ssh/* to /etc/selinux/restorecond_user.conf fixes this issue. This should be added to the defaults I think.

Comment 2 Miroslav Vadkerti 2011-04-01 11:08:26 UTC

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.

Comment 3 Daniel Walsh 2011-04-01 17:17:15 UTC

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.

Comment 4 Miroslav Grepl 2011-04-04 06:14:38 UTC

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

Comment 5 Miroslav Vadkerti 2011-04-04 08:11:02 UTC

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

Comment 6 Miroslav Grepl 2011-04-04 09:05:59 UTC

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.

Comment 7 Miroslav Vadkerti 2011-04-04 10:37:30 UTC

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?

Comment 8 Miroslav Vadkerti 2011-04-04 10:42:32 UTC

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!

Comment 9 Daniel Walsh 2011-04-04 13:33:03 UTC

Miroslav lets add 

	ssh_run_keygen($3,$2)

to ssh_role_template

Comment 10 Miroslav Grepl 2011-04-05 19:12:28 UTC

Fixed in selinux-policy-3.7.19-81.el6

Comment 13 Milos Malik 2011-04-06 08:22:22 UTC

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
$

Comment 14 Milos Malik 2011-04-06 08:38:18 UTC

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 
#

Comment 15 Miroslav Grepl 2011-04-06 10:04:08 UTC

Well, this is a new issue which I am fixing.

Comment 16 Miroslav Grepl 2011-04-06 10:55:35 UTC

Fixed in selinux-policy-3.7.19-82.el6

Comment 18 Daniel Walsh 2011-04-07 14:48:35 UTC

Miroslav did you put this transition into the ssh_role_template?

Comment 19 Miroslav Grepl 2011-04-07 18:10:33 UTC

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.

Comment 20 Miroslav Grepl 2011-04-08 05:32:46 UTC

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)
')

...
...

')

Comment 21 Daniel Walsh 2011-04-08 18:25:29 UTC

Yes we should uncomment that one.

Comment 22 Daniel Walsh 2011-04-08 18:26:23 UTC

Maybe grab the version from F15.

Comment 23 Miroslav Grepl 2011-04-11 10:13:41 UTC

Fixed in selinux-policy-3.7.19-84.el6

Comment 26 errata-xmlrpc 2011-05-19 12:27:26 UTC

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

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