910430 – SELinux is preventing /usr/sbin/sshd from using the 'sys_admin' capabilities.

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 910430 - SELinux is preventing /usr/sbin/sshd from using the 'sys_admin' capabilities.

Summary: SELinux is preventing /usr/sbin/sshd from using the 'sys_admin' capabilities.

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	selinux-policy
Sub Component:
Version:	6.5
Hardware:	x86_64
OS:	Linux
Priority:	high
Severity:	low
Target Milestone:	rc
Target Release:	---
Assignee:	Miroslav Grepl
QA Contact:	Michal Trunecka
Docs Contact:
URL:
Whiteboard:	abrt_hash:a55113d93e8d1bd229165135b0a...
Depends On:	813870
Blocks:
TreeView+	depends on / blocked

Reported:	2013-02-12 16:04 UTC by David Juran
Modified:	2020-03-11 14:49 UTC (History)
CC List:	16 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:	813870
Environment:
Last Closed:	2013-11-21 10:15:51 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2013:1598	0	normal	SHIPPED_LIVE	selinux-policy bug fix and enhancement update	2013-11-20 21:39:24 UTC

Description David Juran 2013-02-12 16:04:40 UTC

+++ This bug was initially created as a clone of Bug #813870 +++

libreport version: 2.0.8
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.3.1-3.fc16.x86_64
reason:         SELinux is preventing /usr/sbin/sshd from using the 'sys_admin' capabilities.
time:           Wed 18 Apr 2012 11:55:02 AM EDT

description:
:SELinux is preventing /usr/sbin/sshd from using the 'sys_admin' capabilities.
:
:*****  Plugin catchall_boolean (89.3 confidence) suggests  *******************
:
:If you want to enable polyinstantiated directory support.
:Then you must tell SELinux about this by enabling the 'allow_polyinstantiation'boolean.
:Do
:setsebool -P allow_polyinstantiation 1
:
:*****  Plugin catchall (11.6 confidence) suggests  ***************************
:
:If you believe that sshd should have the sys_admin capability by default.
:Then you should report this as a bug.
:You can generate a local policy module to allow this access.
:Do
:allow this access for now by executing:
:# grep sshd /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:
:Additional Information:
:Source Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
:Target Context                system_u:system_r:sshd_t:s0-s0:c0.c1023
:Target Objects                 [ capability ]
:Source                        sshd
:Source Path                   /usr/sbin/sshd
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           openssh-server-5.8p2-25.fc16.x86_64
:Target RPM Packages           
:Policy RPM                    selinux-policy-3.10.0-80.fc16.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed) 3.3.1-3.fc16.x86_64 #1 SMP
:                              Wed Apr 4 18:08:51 UTC 2012 x86_64 x86_64
:Alert Count                   2
:First Seen                    Tue 10 Apr 2012 03:00:39 PM EDT
:Last Seen                     Wed 18 Apr 2012 11:50:29 AM EDT
:Local ID                      59104706-d3ef-4249-a64f-3af84a915b34
:
:Raw Audit Messages
:type=AVC msg=audit(1334764229.337:1297): avc:  denied  { sys_admin } for  pid=30579 comm="sshd" capability=21  scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=capability
:
:
:type=SYSCALL msg=audit(1334764229.337:1297): arch=x86_64 syscall=ioctl success=yes exit=0 a0=6 a1=40084301 a2=7fff8a339dc0 a3=8 items=0 ppid=1528 pid=30579 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=153 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
:
:Hash: sshd,sshd_t,sshd_t,capability,sys_admin
:
:audit2allow
:
:#============= sshd_t ==============
:#!!!! This avc can be allowed using the boolean 'allow_polyinstantiation'
:
:allow sshd_t self:capability sys_admin;
:
:audit2allow -R
:
:#============= sshd_t ==============
:#!!!! This avc can be allowed using the boolean 'allow_polyinstantiation'
:
:allow sshd_t self:capability sys_admin;
:

--- Additional comment from Miroslav Grepl on 2012-04-20 14:11:20 CEST ---

Ok, we see it again.

Did it happen by default? Or did you setup pam_namespace?

--- Additional comment from Daniel Scott on 2012-04-20 17:06:00 CEST ---

By default.

--- Additional comment from Daniel Walsh on 2012-04-20 17:29:25 CEST ---

Daniel did you setup anything special in pam?  Did everything seem to work correctly?

--- Additional comment from Daniel Scott on 2012-04-20 17:44:09 CEST ---

I am using FreeIPA for authentication with OpenAFS.

This error occurs when I ssh into my computer as root.

My /etc/pam.d/password-auth file has additional lines to get AFS tokens automatically:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth       [default=done]      pam_afs_session.so always_aklog debug
auth        required      pam_deny.so

account     required      pam_access.so
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_mkhomedir.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
session     required      pam_afs_session.so always_aklog debug

Perhaps this is because root is not a FreeIPA or OpenAFS user?

--- Additional comment from Daniel Walsh on 2012-04-20 17:58:46 CEST ---

You only get it when you log in as root, but if you log in as a normal user, does everything work. IE do you get your proper tokens?

--- Additional comment from Daniel Scott on 2012-04-20 18:05:42 CEST ---

Sorry, I take that back - I get it as 'normal' users too. But I get a ticket and token and can access AFS OK.

--- Additional comment from Daniel Walsh on 2012-04-23 17:27:14 CEST ---

:type=SYSCALL msg=audit(1334764229.337:1297): arch=x86_64 syscall=ioctl
success=yes exit=0 a0=6 a1=40084301 a2=7fff8a339dc0 a3=8 items=0 ppid=1528
pid=30579 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=153 comm=sshd exe=/usr/sbin/sshd
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Actually the syscall is succeeding "success=yes" even though the AVC is generated, so you could safely generate a dontaudit alert for this.  

# grep sys_admin /var/log/audit/audit.log | audit2allow -D -M mysshd
# semodule -i mysshd.pp

I am not sure if this is caused by a problem with our kernel or with the afs kernel module.

--- Additional comment from Miroslav Grepl on 2012-06-28 11:47:29 CEST ---

*** Bug 835975 has been marked as a duplicate of this bug. ***

--- Additional comment from Trond H. Amundsen on 2012-07-20 20:18:35 CEST ---

Just a "me too". I'm seeing this as well, but on RHEL6, and without using pam_afs_session.

--- Additional comment from Daniel Walsh on 2012-07-20 23:33:09 CEST ---

Trond is this happening on an AVS System?

--- Additional comment from Trond H. Amundsen on 2012-07-21 00:24:11 CEST ---

(In reply to comment #10)
> Trond is this happening on an AVS System?

Hm.. I don't know what an AVS system is, so I'm pretty sure that the answer is no :) This is a Dell R720 running web server statistics (Google Urchin) for our site, but I'm not sure if it is in production yet. I've seen this AVC before on other RHEL6 hosts. Tested a few and found one more that has this problem. Also a Dell server, running mysql and some web apps.

Comparing Daniel's /etc/pam.d/password-auth in comment #4 to ours, except for the obvious I can only find one common denominator: pam_sss. I can't tell if that is significant though, I'm not sure what to look for. In my limited testing, this happens consistently on affected servers, for both root (local) and regular users (from SSSD/LDAP).

I'll be happy to perform some (non-desctructive) debugging, but I'll need some guidance on how to proceed.

--- Additional comment from Daniel Walsh on 2012-07-23 16:29:02 CEST ---

AFS, sorry.

--- Additional comment from Trond H. Amundsen on 2012-07-23 16:49:22 CEST ---

(In reply to comment #12)
> AFS, sorry.

Nope, Kerberos isn't in the picture at all. These systems use LDAP (rfc2307, not IPA) and SSSD for authentication.

--- Additional comment from Daniel Walsh on 2012-07-23 17:01:26 CEST ---

Trond what AVC are you seeing?

--- Additional comment from Trond H. Amundsen on 2012-07-23 17:11:13 CEST ---

Here is the AVC that is generated:

type=AVC msg=audit(1343055966.291:482641): avc:  denied  { sys_admin } for  pid=7134 comm="sshd" capability=21  scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=capability

--- Additional comment from Ken Dreyer on 2012-12-12 06:08:26 CET ---

I'm seeing this on my AFS client (Fedora 19). It happens whenever I log in over SSH. I use sssd (Kerberos) and pam_afs_session. My homedir is in AFS.

--- Additional comment from Daniel Walsh on 2012-12-17 22:39:51 CET ---

Ken are you successfully allowed to login?

--- Additional comment from Ken Dreyer on 2012-12-27 03:27:33 CET ---

(In reply to comment #17)
> Ken are you successfully allowed to login?

Yep, I can still log in via SSH. (I'm using "Enforcing".)

I tested with selinux-policy-targeted-3.11.1-67.fc19 today, and SELinux still logs the AVC denial.

--- Additional comment from Daniel Walsh on 2012-12-27 16:48:41 CET ---

Ok I just checked in a fix for this to allow sshd_t sys_admin privs, Looks like it requests it in a couple of different ways so might as well allow it.  sshd_t is already a really powerful domain.

--- Additional comment from Fedora Update System on 2013-01-02 18:37:50 CET ---

selinux-policy-3.11.1-69.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-69.fc18

--- Additional comment from Ken Dreyer on 2013-01-03 03:50:38 CET ---

I can confirm that I no longer get the AVC denial in 3.11.1-69.fc19

--- Additional comment from Miroslav Grepl on 2013-01-03 10:20:51 CET ---

Could you update karma? Thank you for testing.

--- Additional comment from Fedora Update System on 2013-01-04 00:50:50 CET ---

Package selinux-policy-3.11.1-69.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.11.1-69.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-0147/selinux-policy-3.11.1-69.fc18
then log in and leave karma (feedback).

--- Additional comment from Fedora Update System on 2013-01-15 23:20:39 CET ---

selinux-policy-3.11.1-71.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-71.fc18

--- Additional comment from Fedora Update System on 2013-01-23 02:56:03 CET ---

selinux-policy-3.11.1-71.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Miroslav Grepl 2013-06-13 12:00:05 UTC

# sesearch -A -s sshd_t -t sshd_t -c capability 
Found 3 semantic av rules:
   allow sshd_t sshd_t : capability { chown dac_override fowner fsetid kill setgid setuid net_bind_service net_admin ipc_lock sys_chroot sys_admin sys_nice sys_resource sys_tty_config audit_write audit_control } ; 
   allow sshd_t sshd_t : capability { chown fowner fsetid sys_admin } ; 
   allow sshd_t sshd_t : capability net_bind_service

Comment 10 errata-xmlrpc 2013-11-21 10:15:51 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-2013-1598.html

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