Bug 442333

Created attachment 302337 [details]
openswan config

Created attachment 302339 [details]
avc denials

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)

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!

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)

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.

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?
\

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.

openswan-2.6.12-1.el5 was built to address this problem.

So are you saying /sbin/ip some how uses these file descriptors?  This looks
like the unix_stream_socket is still being leaked.

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

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?

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.

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!

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)

2.6.12-2 was built to address this problem.

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