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: | autofs | Assignee: | Ian Kent <ikent> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||
Severity: | low | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 5.0 | CC: | 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
Aleksey Nogin
2007-03-22 18:21:19 UTC
Dan, can you start us of on this one please. Looks like a leaked file descriptor from automount. > 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.
# 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 (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 (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. (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 (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? 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)... 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 (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 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 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.
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. 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. (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 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.
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. 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)
(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. (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. 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? 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. |