Bug 442333 - AVC denials on start of openswan host-to-host tunnel
AVC denials on start of openswan host-to-host tunnel
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openswan (Show other bugs)
5.2
All Linux
high Severity high
: rc
: ---
Assigned To: Steve Grubb
:
Depends On:
Blocks: 253764
  Show dependency treegraph
 
Reported: 2008-04-14 09:45 EDT by Jakub Hrozek
Modified: 2008-05-21 11:29 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2008-0395
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 11:29:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
openswan config (1.34 KB, text/plain)
2008-04-14 09:45 EDT, Jakub Hrozek
no flags Details
avc denials (1.57 KB, text/plain)
2008-04-14 09:47 EDT, Jakub Hrozek
no flags Details
patch to forde the FD_CLOEXEC flag on all opened sockets (23.28 KB, patch)
2008-04-22 08:57 EDT, Neil Horman
no flags Details | Diff
patch to close remaining sockets that we accept (1.90 KB, patch)
2008-04-23 07:59 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Jakub Hrozek 2008-04-14 09:45:56 EDT
Description of problem:
After configuring openswan for host-to-host tunelling on pretty much vanilla 
RHEL5.2 install I get the following AVC denials (full log attached):

---
type=SYSCALL msg=audit(1208179900.369:142): arch=40000003 syscall=4 
success=yes exit=40 a0=8 a1=bfd9a610 a2=28 a3=bfd9aa78 items=0 ppid=3797 
pid=3798 auid=0
 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="pluto" 
exe="/usr/libexec/ipsec/pluto" subj=root:system_r:initrc_t:s0 key=(null)
type=AVC msg=audit(1208179900.389:143): avc:  denied  { read write } for  
pid=3926 comm="ip" path="socket:[12814]" dev=sockfs ino=12814 
scontext=root:system
_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket
type=SYSCALL msg=audit(1208179900.389:143): arch=40000003 syscall=11 
success=yes exit=0 a0=9e2c8c8 a1=9e2e938 a2=9e2ea88 a3=9e2c3b0 items=0 
ppid=3925 pid=39
26 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 
comm="ip" exe="/sbin/ip" subj=root:system_r:ifconfig_t:s0 key=(null)
type=MAC_IPSEC_DELSPD msg=audit(1208179901.421:144): SPD delete: auid=0 
subj=root:system_r:ifconfig_t:s0 src=10.34.34.72 dst=10.34.34.15 res=1
type=SYSCALL msg=audit(1208179901.421:144): arch=40000003 syscall=102 
success=yes exit=16 a0=10 a1=bff7f870 a2=bff83914 a3=bff83938 items=0 
ppid=3915 pid=39
32 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 
comm="ip" exe="/sbin/ip" subj=root:system_r:ifconfig_t:s0 key=(null)
type=AVC msg=audit(1208179902.257:145): avc:  denied  { read write } for  
pid=4119 comm="ip" path="socket:[13121]" dev=sockfs ino=13121 
scontext=root:system
_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket
type=SYSCALL msg=audit(1208179902.257:145): arch=40000003 syscall=11 
success=yes exit=0 a0=8641380 a1=86415f8 a2=8648aa8 a3=86412a0 items=0 
ppid=4118 pid=41
19 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 
comm="ip" exe="/sbin/ip" subj=root:system_r:ifconfig_t:s0 key=(null)
type=AVC msg=audit(1208179902.285:146): avc:  denied  { read write } for  
pid=4122 comm="ip" path="socket:[13121]" dev=sockfs ino=13121 
scontext=root:system
_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 tclass=unix_stream_socket
---

The errors are similar on both ends.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-2.4.6-128.el5

How reproducible:
always


Steps to Reproduce:
1. configure host-to-host tunnel with openswan (my config file attached)
2. modprobe af_key
3. service ipsec start
  
Actual results:
avc denials

Expected results:
no avc denials

Additional info:
It seems that despite these denials, host-to-host encryption works (verified 
that tcpdump shows ESP packets when pinging from one end to the other), but I 
guess that these could indicate some error later on..also CC-ing package owner 
for that reason.
Comment 1 Jakub Hrozek 2008-04-14 09:45:56 EDT
Created attachment 302337 [details]
openswan config
Comment 2 Jakub Hrozek 2008-04-14 09:47:30 EDT
Created attachment 302339 [details]
avc denials
Comment 3 Daniel Walsh 2008-04-14 10:44:30 EDT
These are leaked file descriptors.  They can be ignored from an SELinux perspective.

openswan should close all descriptors on exec

fcntl(fd, F_SETFD, FD_CLOSEXEC)

Comment 9 Neil Horman 2008-04-22 08:57:15 EDT
Created attachment 303301 [details]
patch to forde the FD_CLOEXEC flag on all opened sockets

based on dan walsh's comments, I've written this patch which should force all
open sockets to close on exec (which may be overkill, given that only unix
stream sockets were logged as avc denials).  But given that this wasn't a
completely covering test case, and I can't see any place where we need to have
children inherit our sockets, I thought better safe than sorry.  If you could
please test this out and let me know if it fixes the problem, I'll send it to
everyone who needs it.	Thanks!
Comment 10 Jakub Hrozek 2008-04-22 11:15:34 EDT
I applied the patch on top of openswan 2.6.11 and it's better - but I still 
see some avc denials (rhel5.2 nighly, host-to-host tunnel, config file same as 
in the opening comment, relabeled filesystem before the test)

on "service ipsec stop":
type=AVC msg=audit(1208877088.517:84): avc:  denied  { read write } for  
pid=3724 comm="ip" path="socket:[9064]" dev=sockfs ino=9064 
scontext=system_u:system_r:ifconfig_t:s0 
tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=SYSCALL msg=audit(1208877088.517:84): arch=40000003 syscall=11 
success=yes exit=0 a0=8379b98 a1=837ac90 a2=837bd58 a3=0 items=0 ppid=3723 
pid=3724 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 
fsgid=0 tty=(none) ses=4294967295 comm="ip" exe="/sbin/ip" 
subj=system_u:system_r:ifconfig_t:s0 key=(null)

on "service ipsec start":
type=AVC msg=audit(1208877097.674:85): avc:  denied  { read write } for  
pid=3904 comm="ip" path="socket:[11059]" dev=sockfs ino=11059 
scontext=root:system_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 
tclass=unix_stream_socket
type=SYSCALL msg=audit(1208877097.674:85): arch=40000003 syscall=11 
success=yes exit=0 a0=89bf248 a1=89bf4c0 a2=89c6980 a3=0 items=0 ppid=3903 
pid=3904 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=pts0 ses=1 comm="ip" exe="/sbin/ip" subj=root:system_r:ifconfig_t:s0 
key=(null)
type=AVC msg=audit(1208877097.694:86): avc:  denied  { read write } for  
pid=3907 comm="ip" path="socket:[11059]" dev=sockfs ino=11059 
scontext=root:system_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 
tclass=unix_stream_socket
type=SYSCALL msg=audit(1208877097.694:86): arch=40000003 syscall=11 
success=yes exit=0 a0=9ef2780 a1=9ef47e8 a2=9ef4938 a3=0 items=0 ppid=3906 
pid=3907 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 
tty=pts0 ses=1 comm="ip" exe="/sbin/ip" subj=root:system_r:ifconfig_t:s0 
key=(null)
Comment 11 Paul Wouters 2008-04-22 11:38:19 EDT
Openswan needs access to the routing table via the ip command. Options like
leftsourceip= manipulate the routing table, even when NETKEY and not KLIPS is used.
Comment 12 Neil Horman 2008-04-22 12:08:13 EDT
yeah, the remaining messages come from the ip utility which openswan uses to
access the routing table, via its my_system call.  

I am assuming that these messages don't occur if the routing table is
manipulated when ip is called from the shell directly as an appropriate user. 
Dan, do we just need to extend openswans targeted policy to include appropriate
rights for openswan to use iproute to preform the above actions, or are these
messages indicative of something that needs to be fixed in iproute directly?
\

Comment 14 Neil Horman 2008-04-22 13:34:32 EDT
I'm reassigning this to steve so that he can track this patch's inclusion into
snap7.  I've opened bz 443646 to track the remaining avc deinals that are not
strictly within openswan.
Comment 16 Steve Grubb 2008-04-22 14:36:56 EDT
openswan-2.6.12-1.el5 was built to address this problem.
Comment 17 Daniel Walsh 2008-04-22 15:26:04 EDT
So are you saying /sbin/ip some how uses these file descriptors?  This looks
like the unix_stream_socket is still being leaked.
Comment 18 Neil Horman 2008-04-22 16:30:34 EDT
the patch to openswan is attached, I've wrapped every socket call up in a
wrapper that forces close on exec, and I don't find any calls to open socket
files directly, so I'm not sure what we could be missing.  Looking at the
iproute2 package I see at least 1 site at which we're attempting to open a
conection oriented AF_UNIX socket .  I don't know if that helps you any, but I'm
fairly confident that we're not leaking any more open file descriptors
Comment 19 Daniel Walsh 2008-04-22 17:01:54 EDT
type=AVC msg=audit(1208877097.694:86): avc:  denied  { read write } for  
pid=3907 comm="ip" path="socket:[11059]" dev=sockfs ino=11059 
scontext=root:system_r:ifconfig_t:s0 tcontext=root:system_r:initrc_t:s0 
tclass=unix_stream_socket


This says that the ip command comm="ip" is trying to read/write a socket owned
by another process owned by initrc_t.

Are you closing any sockets that you create or accept?
Comment 20 Neil Horman 2008-04-23 07:59:05 EDT
Created attachment 303484 [details]
patch to close remaining sockets that we accept

dang, sorry steve, dan's right, I neglected to check for sockets that we
accept. I'd forgotten that we don't inherit flags from our parent socket
descriptor.  This patch, when applied in addition to my previous patch should
take care of the remaining AVC denials.
Comment 21 Jakub Hrozek 2008-04-23 08:46:19 EDT
With the second patch, all looks good - I didn't see any more avc denials 
during my quick testing, I'll report here if I find any.. 

Thanks, Neil!
Comment 22 Paul Wouters 2008-04-23 09:04:45 EDT
We've applied the patches, and it will be in openswan 2.6.13. (except we called
the include file socketwrapper.h to avoid confusion with system includes)
Comment 23 Steve Grubb 2008-04-23 15:30:07 EDT
2.6.12-2 was built to address this problem.
Comment 27 errata-xmlrpc 2008-05-21 11:29:11 EDT
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 the 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-2008-0395.html

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