Bug 1174249

Summary: AVC denied for OpenVPN for block_suspend for tclass=capability2
Product: Red Hat Enterprise Linux 7 Reporter: Robert Scheck <redhat-bugzilla>
Component: selinux-policyAssignee: Simon Sekidde <ssekidde>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: lmiksik, lvrabec, mgrepl, mmalik, ovasik, plautrba, pvrabec, robert.scheck, ssekidde
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.13.1-15.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 10:47:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert Scheck 2014-12-15 13:47:24 UTC
Description of problem:
type=AVC msg=audit(1418385621.665:8029): avc:  denied  { block_suspend } for  pid=16389 comm="openvpn" capability=36  scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=capability2
type=SYSCALL msg=audit(1418385621.665:8029): arch=x86_64 syscall=epoll_ctl success=yes exit=0 a0=7 a1=2 a2=8 a3=7fff57392620 items=0 ppid=1 pid=16389 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=openvpn exe=/usr/sbin/openvpn subj=system_u:system_r:openvpn_t:s0 key=(null)

Version-Release number of selected component (if applicable):
openvpn-2.3.6-1.el7.x86_64
selinux-policy-3.12.1-153.el7_0.12.noarch
selinux-policy-targeted-3.12.1-153.el7_0.12.noarch

How reproducible:
No idea when this happens explicitly, but once in a while somehow.

Actual results:
AVC denied for OpenVPN for block_suspend for tclass=capability2.

Expected results:
No AVC denied.

Comment 1 Robert Scheck 2014-12-15 13:48:47 UTC
Cross-filed case #01319842 on the Red Hat Customer Portal.

Comment 3 Simon Sekidde 2014-12-17 19:05:44 UTC
Robert, 

I'm not sure whats going on but this is allowed for scripts labeled openvpn_unconfined_script_t

Comment 4 Robert Scheck 2014-12-17 21:22:10 UTC
No matter if it helps, but:

# ps auxZ | grep -i vpn
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 15363 0.0  0.0 112652 972 pts/2 R+ 22:16   0:00 grep --color=auto -i vpn
system_u:system_r:openvpn_t:s0  root     16124  0.0  0.0  51796  2636 ?        Ss   Dez11   1:06 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/road-server.pid --cd /etc/openvpn/ --config road-server.conf
system_u:system_r:openvpn_t:s0  root     16389  0.0  0.0  52372  2088 ?        Ss   Dez11   0:11 /usr/sbin/openvpn --daemon --writepid /var/run/openvpn/road-server-tcp.pid --cd /etc/openvpn/ --config road-server-tcp.conf
# 

We do not have "client-connect" or "client-disconnect" in the *.conf (which
is the only thing I know related to "openvpn_unconfined_script_t").

What is block_suspend for tclass=capability2 exactly? I am even unsure if it
deserves a dontaudit or an allow (we are running permissive here for other
reasons, so I don't know if a denial would have actually impact).

Comment 5 Robert Scheck 2014-12-17 21:36:22 UTC
(In reply to Robert Scheck from comment #4)
> What is block_suspend for tclass=capability2 exactly? I am even unsure if it
> deserves a dontaudit or an allow (we are running permissive here for other
> reasons, so I don't know if a denial would have actually impact).

Ush, I read the RHBZ before the ticket, https://lwn.net/Articles/520198/ is
answering it indeed.

No matter if it helps, but the following OpenVPN events were logged one second
before or in the same second (related to the AVC denied):

Dec 12 14:26:41 tux openvpn[16389]: MULTI: new connection by client 'Tux' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.

Dec 12 16:22:47 tux openvpn[16389]: Tux/192.0.2.53:2363 Connection reset, restarting [-1]
Dec 12 16:22:47 tux openvpn[16389]: Tux/192.0.2.53:2363 SIGUSR1[soft,connection-reset] received, client-instance restarting

However these events are not really easy to reproduce IMHO, I would need a
buggy Internet connectivity ;-) Maybe that event is even not related.

Comment 7 Robert Scheck 2015-01-12 12:58:40 UTC
May I ask what the fix is?

Comment 8 Milos Malik 2015-01-12 14:39:26 UTC
dontaudit rule for that kind of access

Comment 9 Miroslav Grepl 2015-01-12 15:15:21 UTC
Yes, this is a kernel bug and we added dontaudit rule until a kernel fix.

Comment 14 errata-xmlrpc 2015-03-05 10:47: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.

https://rhn.redhat.com/errata/RHBA-2015-0458.html