Bug 233481

Summary: SELinux audit messages "/bin/umount (mount_t) "read write" to socket:[NNN] (automount_t)"
Product: Red Hat Enterprise Linux 5 Reporter: Aleksey Nogin <aleksey>
Component: autofsAssignee: Ian Kent <ikent>
Status: CLOSED WONTFIX QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: low Docs Contact:
Priority: medium    
Version: 5.0CC: dwalsh, jakub, jmoyer, lmiksik, ovasik, t.matsuu
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-17 07:03:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 452122, 993477    
Bug Blocks: 928849    
Attachments:
Description Flags
Don't leak any file descriptors on exec()
none
Attempt to use mutex to prevent leaked file descriptors on exec() none

Description Aleksey Nogin 2007-03-22 18:21:19 UTC
I am getting the following in my logs with autofs-5.0.1-0.rc2.43.0.2 on RHEL5:

% dmesg
...
Mar 21 17:41:31 XXX setroubleshoot:      SELinux is preventing /bin/umount
(mount_t) "read write" to socket:[964509] (automount_t).      For complete
SELinux messages. run sealert -l 619111cc-de7d-4e74-aaf4-6ff9fc0a4c11
Mar 22 09:59:05 XXX setroubleshoot:      SELinux is preventing /bin/mount
(mount_t) "read write" to socket:[1440127] (automount_t).      For complete
SELinux messages. run sealert -l 803e8a01-6ba1-4e70-b9b4-d236309513a7
Mar 22 09:59:05 XXX setroubleshoot:      SELinux is preventing /bin/mount
(mount_t) "read write" to socket:[1440527] (automount_t).      For complete
SELinux messages. run sealert -l c7b25a24-dbda-4c93-9ef0-9de2667b3e71
Mar 22 09:59:32 XXX setroubleshoot:      SELinux is preventing /bin/mount
(mount_t) "read write" to socket:[1503463] (automount_t).      For complete
SELinux messages. run sealert -l 4f3f188e-817c-4ee8-86be-40db19f6a075

% sealert -l 619111cc-de7d-4e74-aaf4-6ff9fc0a4c11
Summary
    SELinux is preventing /bin/umount (mount_t) "read write" to socket:[964509]
    (automount_t).

Detailed Description
    [...]
    
Allowing Access
    [...]

Additional Information

Source Context                system_u:system_r:mount_t
Target Context                system_u:system_r:automount_t
Target Objects                socket:[964509] [ unix_stream_socket ]
Affected RPM Packages         util-linux-2.13-0.44.el5 [application]
Policy RPM                    selinux-policy-2.4.6-30.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall
Host Name                     XXX
Platform                      Linux XXX 2.6.18-8.1.1.el5 #1 SMP Mon
                              Feb 26 20:38:02 EST 2007 i686 i686
Alert Count                   1
Line Numbers

Raw Audit Messages

avc: denied { read, write } for comm="umount" dev=sockfs egid=0 euid=0
exe="/bin/umount" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="[964509]"
path="socket:[964509]" pid=24744 scontext=system_u:system_r:mount_t:s0 sgid=0
subj=system_u:system_r:mount_t:s0 suid=0 tclass=unix_stream_socket
tcontext=system_u:system_r:automount_t:s0 tty=(none) uid=0

The /etc/auto.master ends with a "+auto.master" line and the auto.master map on
YP contains references to both indirect and direct mount maps.

Potentially related FC bugs: bug 207678, bug 215757.

Comment 1 Ian Kent 2007-03-23 01:48:40 UTC
Dan, can you start us of on this one please.

Comment 2 Daniel Walsh 2007-03-23 14:03:04 UTC
Looks like a leaked file descriptor from automount.

Comment 3 Jeff Moyer 2007-04-04 18:56:29 UTC
> Target Objects                socket:[964509] [ unix_stream_socket ]

Autofs doesn't create any unix domain sockets.  It does create pipes, but they
should show up differently, right?  Could this be a library leaking the socket?

We really need more information on the automount configuration so we can isolate
the problem.  Please include maps and the output from 'grep "^automount"
/etc/nsswitch.conf".

Thanks.

Comment 4 Aleksey Nogin 2007-04-05 00:08:02 UTC
# grep "^automount" /etc/nsswitch.conf
automount:  files nis

The /etc/auto.master is the default one. The auto.master on YP contains:

/home auto.home
/- auto.direct


Comment 5 Ian Kent 2007-04-05 02:55:09 UTC
(In reply to comment #3)
> > Target Objects                socket:[964509] [ unix_stream_socket ]
> 
> Autofs doesn't create any unix domain sockets.  It does create pipes, but they
> should show up differently, right?  Could this be a library leaking the socket?

I missed that and we certainly don't use PF_UNIX or PF_LOCAL
sockets anywhere in autofs itself.

This is the peril of selinux requiring that an application be
responsible "all" file handles, some of which it has no control
over.

Somehow we will need to identify which library is doing this
and make a patch to set the close-on-exec bit for the file
handle.

Dan, can you confirm that the "unix_stream_socket" refered to
above really is one that would be created with a domain of
PF_UNIX or PF_LOCAL?

Ian


Comment 6 Jeff Moyer 2007-05-31 19:01:53 UTC
(In reply to comment #5)
> Somehow we will need to identify which library is doing this
> and make a patch to set the close-on-exec bit for the file
> handle.

Ian, I wonder if this is the syslog library.  I guess we could try doing a
closelog(), but I don't see how this buys us security.

Comment 7 Ian Kent 2007-06-01 03:46:58 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Somehow we will need to identify which library is doing this
> > and make a patch to set the close-on-exec bit for the file
> > handle.
> 
> Ian, I wonder if this is the syslog library.  I guess we could try doing a
> closelog(), but I don't see how this buys us security.

Good point, when I ported the OpenBSD re-entrant syslog for
version 4 I remember it opened a unix socket and didn't set
the close on exec. The code was very similar to that in glibc.
I'll grab an updated glibc source and have a look.

Ian


Comment 8 Jeff Moyer 2007-07-20 22:29:05 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Somehow we will need to identify which library is doing this
> > > and make a patch to set the close-on-exec bit for the file
> > > handle.
> > 
> > Ian, I wonder if this is the syslog library.  I guess we could try doing a
> > closelog(), but I don't see how this buys us security.
> 
> Good point, when I ported the OpenBSD re-entrant syslog for
> version 4 I remember it opened a unix socket and didn't set
> the close on exec. The code was very similar to that in glibc.
> I'll grab an updated glibc source and have a look.

glibc-2.5-20061008T1257 sets the close-on-exec bit.

Aleksey, can you provide an strace of the automounter showing this problem?

Comment 9 Aleksey Nogin 2007-07-20 23:40:39 UTC
The machine currently has glibc-2.5-12. I am not sure whether I can do an strace
as this problem is fairly rare (a few times a day, at most) and I do not know
how to cause it to happen at a particular time (and I would prefer not to run
automount under strace for a day)...

Comment 10 Aleksey Nogin 2007-07-20 23:55:16 UTC
P.S. Actually, I just realized that I am have not seen this message for quite a
while (at least a month). What I am getting these days is the following (where
the 2551 is the pid of the automount process):

Summary
    SELinux prevented /bin/umount from mounting on the file or directory
    "/proc/2551/mounts" (type "automount_t").

Detailed Description
    SELinux prevented /bin/umount from mounting a filesystem on the file or
    directory "/proc/2551/mounts" of type "automount_t". By default SELinux
    limits the mounting of filesystems to only some files or directories (those
    with types that have the mountpoint attribute). The type "automount_t" does
    not have this attribute. You can either relabel the file or directory or set
    the boolean "allow_mount_anyfile" to true to allow mounting on any file or
    directory.

Allowing Access
    Changing the "allow_mount_anyfile" boolean to true will allow this access:
    "setsebool -P allow_mount_anyfile=1."

    The following command will allow this access:
    setsebool -P allow_mount_anyfile=1

Additional Information

Source Context                system_u:system_r:mount_t
Target Context                system_u:system_r:automount_t
Target Objects                /proc/2551/mounts [ file ]
Affected RPM Packages         util-linux-2.13-0.44.el5 [application]
Policy RPM                    selinux-policy-2.4.6-30.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.allow_mount_anyfile
Host Name                     XXX
Platform                      Linux XXX 2.6.18-8.1.4.el5 #1 SMP Fri
                              May 4 22:15:13 EDT 2007 i686 i686
Alert Count                   15
Line Numbers

Raw Audit Messages

avc: denied { read } for comm="umount" dev=proc egid=0 euid=0 exe="/bin/umount"
exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="mounts" path="/proc/2551/mounts"
pid=2186 scontext=system_u:system_r:mount_t:s0 sgid=0
subj=system_u:system_r:mount_t:s0 suid=0 tclass=file
tcontext=system_u:system_r:automount_t:s0 tty=(none) uid=0


Comment 11 Jeff Moyer 2007-08-16 19:44:23 UTC
(In reply to comment #10)
> P.S. Actually, I just realized that I am have not seen this message for quite a
> while (at least a month). What I am getting these days is the following (where
> the 2551 is the pid of the automount process):
> 
> avc: denied { read } for comm="umount" dev=proc egid=0 euid=0 exe="/bin/umount"
> exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="mounts" path="/proc/2551/mounts"
> pid=2186 scontext=system_u:system_r:mount_t:s0 sgid=0
> subj=system_u:system_r:mount_t:s0 suid=0 tclass=file
> tcontext=system_u:system_r:automount_t:s0 tty=(none) uid=0

Do you have /etc/mtab symlinked to /proc/mounts or something?

-Jeff

Comment 12 mike orstead 2007-08-30 15:31:50 UTC
I am also seeing the same messages as the original report...  Any new info/fixes
would be much appreciated.  I attempted to run an strace against automount, as
our issue appears very regularly, however, attempting a forking strace against
automount hung the process up after termination of the strace  =[


Aug 30 07:40:14 racprd03 setroubleshoot:      SELinux is preventing /bin/mount
(mount_t) "read write" to socket:[27647256] (automount_t).      For complete
SELinux messages. run sealert -l b64bb4ee-b936-4ec7-9424-725c2aba95f1
# sealert -l b64bb4ee-b936-4ec7-9424-725c2aba95f1
Summary
    SELinux is preventing /bin/mount (mount_t) "read write" to socket:[27647256]
    (automount_t).

Detailed Description
    SELinux denied access requested by /bin/mount. It is not expected that this
    access is required by /bin/mount and this access may signal an intrusion
    attempt. It is also possible that the specific version or configuration of
    the application is causing it to require additional access.

Allowing Access
    You can generate a local policy module to allow this access - see
    http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable
    SELinux protection altogether. Disabling SELinux protection is not
    recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
    against this package.

Additional Information

Source Context                system_u:system_r:mount_t
Target Context                system_u:system_r:automount_t
Target Objects                socket:[27647256] [ tcp_socket ]
Affected RPM Packages         util-linux-2.13-0.44.el5 [application]
Policy RPM                    selinux-policy-2.4.6-30.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall
Host Name                     racprd03
Platform                      Linux racprd03 2.6.18-8.el5 #1 SMP Fri Jan 26
                              14:15:14 EST 2007 x86_64 x86_64
Alert Count                   408
Line Numbers

Raw Audit Messages

avc: denied { read, write } for comm="mount" dev=sockfs egid=0 euid=0
exe="/bin/mount" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="[45593007]"
path="socket:[27647256]" pid=15761 scontext=system_u:system_r:mount_t:s0 sgid=0
subj=system_u:system_r:mount_t:s0 suid=0 tclass=tcp_socket
tcontext=system_u:system_r:automount_t:s0 tty=(none) uid=0

##
I am using ldap (on Sun's Directory Server 5.2p4) for our automount info, with
the following autofs setup on the clients:

Schema definition in /etc/sysconfig/autofs   (all else defaults):
DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="automountMapName"
DEFAULT_ENTRY_ATTRIBUTE="automountKey"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"


/etc/autofs_ldap_auth.conf:
<autofs_ldap_sasl_conf
        usetls="no"
        tlsrequired="no"
        authrequired="no"
/>

/etc/auto.master:
/misc   /etc/auto.misc
/net    -hosts
+auto.master
/home   ldap:automountMapName=auto_linux_home,dc=ourdomain,dc=com
/share  ldap:automountMapName=auto_share,dc=ourdomain,dc=com
/app    ldap:automountMapName=auto_app,dc=ourdomain,dc=com

##
## We're running kernel 2.6.18-8.el5   and glibc 2.5-12

Thanks,
Mike


Comment 13 Jeff Moyer 2007-09-18 18:14:46 UTC
Created attachment 198661 [details]
Don't leak any file descriptors on exec()

The problem seen here stems from multiple lookups/mounts/unmounts happening at
the same time.	If, for example, two lookups are performed, one thread in the
automounter may be performing a mount while another thead is issuing a DNS
query or opening an LDAP connection.  When such a race occurs, we can end up
calling exec() with some open file descriptors that do not have FD_CLOEXEC set.


In reality, this problem warrants little attention.  But, since SELinux is
complaining about it, we'll fix it.  The attached patch simply closes file
descriptors before exec.  There's still a small race, but the window is minute.

Comment 15 RHEL Program Management 2007-10-16 04:03:15 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 17 Jeff Moyer 2007-11-26 20:22:37 UTC
Ian, I'm handing this off to you since you are handling the autofs v5 bugs.  The
patch has a lengthy comment describing what it does and why.  You can also refer
to comment #13 for further analysis.

Comment 18 Ian Kent 2007-11-27 01:53:23 UTC
(In reply to comment #17)
> Ian, I'm handing this off to you since you are handling the autofs v5 bugs.  The
> patch has a lengthy comment describing what it does and why.  You can also refer
> to comment #13 for further analysis.

I've been thinking about this too.

The solution in comment #13 may appear to work and likely will
most of the time but autofs v5 explicitly sets the maximum open
file count to about 10000 so we can't be sure that closing the
first 1024 descriptors is sufficient and the overhead of closing
10000 file descriptors on every spawn/exec call would be high. At
the moment I think I need to add yet another mutex abound the
spawn/exec and all the open/close-on-exec calls but I also need
to go through and work out which library functions need to be
surrounded with the mutex as well.

Ian


Comment 19 Ian Kent 2007-12-03 10:03:54 UTC
Created attachment 275541 [details]
Attempt to use mutex to prevent leaked file descriptors on exec()

This patch attempts to use a mutex to ensure that no file
handles are in the process of being opened during an exec.
This patch is against current CVS autofs, revision 0.rc2.70.
If a z-stream update is needed then more work applying
dependent patches will be needed.

Comment 22 RHEL Program Management 2008-06-02 20:38:30 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 24 Takanori MATSUURA 2008-12-24 05:21:52 UTC
I also catch the lessage like here on my Fedora 10.
In my environment, home directory is automounted by auto.home which is provided by NIS.
If attachment 275541 [details] fixes this, could you test it on Fedora 10?


$ sealert -l 0e8dd15f-3f2b-4c4a-9eaf-f5598b5bf0e2

Summary:

SELinux prevented umount from mounting on the file or directory "/proc/<pid>/mounts"
(type "automount_t").

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux prevented umount from mounting a filesystem on the file or directory
"/proc/<pid>/mounts" of type "automount_t". By default SELinux limits the
mounting of filesystems to only some files or directories (those with types that
have the mountpoint attribute). The type "automount_t" does not have this
attribute. You can either relabel the file or directory or set the boolean
"allow_mount_anyfile" to true to allow mounting on any file or directory.

Allowing Access:

Changing the "allow_mount_anyfile" boolean to true will allow this access:
"setsebool -P allow_mount_anyfile=1."

Fix Command:

setsebool -P allow_mount_anyfile=1

Additional Information:

Source Context                system_u:system_r:mount_t:s0
Target Context                system_u:system_r:automount_t:s0
Target Objects                /proc/<pid>/mounts [ file ]
Source                        umount
Source Path                   /bin/umount
Port                          <Unknown>
Host                          sx-lx3.protein.net
Source RPM Packages           util-linux-ng-2.14.1-3.1.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-34.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   allow_mount_anyfile
Host Name                     sx-lx3.protein.net
Platform                      Linux sx-lx3.protein.net 2.6.27.7-134.fc10.x86_64
                              #1 SMP Mon Dec 1 22:21:35 EST 2008 x86_64 x86_64
Alert Count                   1
First Seen                    Wed Dec 24 13:37:16 2008
Last Seen                     Wed Dec 24 13:37:16 2008
Local ID                      0e8dd15f-3f2b-4c4a-9eaf-f5598b5bf0e2
Line Numbers                  

Raw Audit Messages            

node=sx-lx3.protein.net type=AVC msg=audit(1230093436.86:4528): avc:  denied  { read } for  pid=2513 comm="umount" path="/proc/2204/mounts" dev=proc ino=5005475 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:automount_t:s0 tclass=file

node=sx-lx3.protein.net type=SYSCALL msg=audit(1230093436.86:4528): arch=c000003e syscall=59 success=yes exit=0 a0=7f5d1cdeee90 a1=7f5d1cdede20 a2=7f5d1ed85330 a3=7f5d1cded070 items=0 ppid=2204 pid=2513 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="umount" exe="/bin/umount" subj=system_u:system_r:mount_t:s0 key=(null)

Comment 25 Ian Kent 2008-12-24 14:13:27 UTC
(In reply to comment #24)
> I also catch the lessage like here on my Fedora 10.
> In my environment, home directory is automounted by auto.home which is provided
> by NIS.
> If attachment 275541 [details] fixes this, could you test it on Fedora 10?

Currently I don't think this problem is fixable by changes to
autofs. I'll need do more investigation when I return to working
on it.

Comment 26 Ian Kent 2008-12-24 14:20:38 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > I also catch the lessage like here on my Fedora 10.
> > In my environment, home directory is automounted by auto.home which is provided
> > by NIS.
> > If attachment 275541 [details] [details] fixes this, could you test it on Fedora 10?
> 
> Currently I don't think this problem is fixable by changes to
> autofs. I'll need do more investigation when I return to working
> on it.

I take that back. For a bit I was thinking the pipe file handle
itself was causing this but that is re-directs std io which I believe
shouldn't be a problem.

Note that the patch you referred to above was considered not
to be adequate as a solution and, while recent kernels provide
a method to resolve this that work hasn't been done and this
feature isn't available in RHEL.

Comment 32 Ian Kent 2009-11-25 04:02:57 UTC
As far as I can see the needed support for atomic close-on-exec
isn't present in the current RHEL-5 glibc (and I presume not
present in the kernel).

Jakub, is it worth adding autofs support for this in case it
is included in the future or is this too large a change to
expect to see it in RHEL-5?

Comment 38 Ondrej Vasik 2013-05-17 07:03:22 UTC
The required glibc and kernel changes aren't present in RHEL-5 and aren't likely to be as RHEL-5 is now in production phase 2. Closing WONTFIX.