From mboxrd@z Thu Jan 1 00:00:00 1970 From: Taylor_Tad@emc.com Subject: Question about setting watches in auto-mounted directories in RHEL 5.2 Date: Fri, 21 Nov 2008 11:59:46 -0500 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0674360162==" Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mALH0G0C022978 for ; Fri, 21 Nov 2008 12:00:16 -0500 Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id mALH05Ew018750 for ; Fri, 21 Nov 2008 12:00:05 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id mALH010Q002173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Nov 2008 12:00:04 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor) for ; Fri, 21 Nov 2008 11:46:58 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id mALGxr4i016965 for ; Fri, 21 Nov 2008 11:59:55 -0500 (EST) Content-class: urn:content-classes:message List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============0674360162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94BFA.8F0B8515" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94BFA.8F0B8515 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to set a file system watch so that any activity in an auto-mounted directory is audited. It looks like just setting a watch on a parent directory isn't sufficient. For example, if I have directory path /dir1/dir2 and auto-mount something at /dir1/dir2/mount-dir, setting a file system watch on /dir1/dir2 doesn't detect activity in the auto-mounted subtree. Looking at the auditctl man page, it looks like I'd have to issue a command like "/sbin/auditctl -q /dir1/dir2/mount-dir,/dir1/dir2" to tell the kernel to watch the newly mounted file system as well. Unfortunately, auto-mounts are, well, automatic, so there's no one to issue that command. =20 Am I missing a better way to accomplish this goal? Is my understanding wrong? Any help would be appreciated. Thanks, =20 --Tad Taylor ------_=_NextPart_001_01C94BFA.8F0B8515 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to set a file system watch so that = any activity in an auto-mounted directory is audited.  It looks like just = setting a watch on a parent directory isn’t sufficient.  For example, = if I have directory path  /dir1/dir2 and auto-mount something at /dir1/dir2/mount-dir, setting a file system watch on /dir1/dir2 = doesn’t detect activity in the auto-mounted subtree.  Looking at the = auditctl man page, it looks like I’d have to issue a command like = “/sbin/auditctl –q /dir1/dir2/mount-dir,/dir1/dir2” to tell the kernel to = watch the newly mounted file system as well.  Unfortunately, auto-mounts are, = well, automatic, so there’s no one to issue that command.

 

Am I missing a better way to accomplish this = goal?  Is my understanding wrong?  Any help would be appreciated.  = Thanks,

 

--Tad Taylor

------_=_NextPart_001_01C94BFA.8F0B8515-- --===============0674360162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0674360162==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Question about setting watches in auto-mounted directories in RHEL 5.2 Date: Sun, 30 Nov 2008 09:15:52 -0500 Message-ID: <200811300915.52390.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: Taylor_Tad@emc.com List-Id: linux-audit@redhat.com Hi, I was hoping one of the kernel people would have answered this or taken note on something that may need fixing...but they didn't. On Friday 21 November 2008 11:59:46 Taylor_Tad@emc.com wrote: > I'd like to set a file system watch so that any activity in an > auto-mounted directory is audited. You can't at this point in time. When the rule is loaded, it needs to resolve the path down to a device and inode. If the file system is not mounted, it cannot do this and the rule is rejected. > It looks like just setting a watchon a parent directory isn't sufficient. For > example, if I have directory path /dir1/dir2 and auto-mount something at > /dir1/dir2/mount-dir, setting a file system watch on /dir1/dir2 doesn't > detect activity in the auto-mounted subtree. True. > Looking at the auditctl man page, it looks like I'd have to issue a command > like "/sbin/auditctl -q /dir1/dir2/mount-dir,/dir1/dir2" to tell the kernel > to watch the newly mounted file system as well. Yes. > Unfortunately, auto-mounts are, well, automatic, so there's no one to issue > that command. I haven't looked into hal scripting deeply, but there may be some chances there, but it might not be easy to figure out where to add the command. > Am I missing a better way to accomplish this goal? Is my understanding > wrong? Not that I know of. We talked about needing to do this 2 years ago when the file system audit code was being written, but they never addressed the problem. I'd really like to see this fixed somehow. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro Subject: Re: Question about setting watches in auto-mounted directories in RHEL 5.2 Date: Sun, 30 Nov 2008 10:11:10 -0500 Message-ID: <20081130151040.GC14693@file.rdu.redhat.com> References: <200811300915.52390.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200811300915.52390.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Taylor_Tad@emc.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Sun, Nov 30, 2008 at 09:15:52AM -0500, Steve Grubb wrote: > On Friday 21 November 2008 11:59:46 Taylor_Tad@emc.com wrote: > > I'd like to set a file system watch so that any activity in an > > auto-mounted directory is audited. > > You can't at this point in time. When the rule is loaded, it needs to resolve > the path down to a device and inode. If the file system is not mounted, it > cannot do this and the rule is rejected. > > > > It looks like just setting a watchon a parent directory isn't sufficient. For > > example, if I have directory path /dir1/dir2 and auto-mount something at > > /dir1/dir2/mount-dir, setting a file system watch on /dir1/dir2 doesn't > > detect activity in the auto-mounted subtree. > > True. > > > Looking at the auditctl man page, it looks like I'd have to issue a command > > like "/sbin/auditctl -q /dir1/dir2/mount-dir,/dir1/dir2" to tell the kernel > > to watch the newly mounted file system as well. > > Yes. > > > > Unfortunately, auto-mounts are, well, automatic, so there's no one to issue > > that command. You do realize that they are, in the end, done from userland? Which is the natural place to do that... From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Question about setting watches in auto-mounted directories in RHEL 5.2 Date: Sun, 30 Nov 2008 10:47:07 -0500 Message-ID: <200811301047.07796.sgrubb@redhat.com> References: <200811300915.52390.sgrubb@redhat.com> <20081130151040.GC14693@file.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20081130151040.GC14693@file.rdu.redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Alexander Viro Cc: Taylor_Tad@emc.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Sunday 30 November 2008 10:11:10 Alexander Viro wrote: > > > Unfortunately, auto-mounts are, well, automatic, so there's no one = to > > > issue that command. > > You do realize that they are, in the end, done from userland? =A0Which = is > the natural place to do that... The problem is that's a little racy. But more importantly, it would be ni= ce to=20 load rules once since there is a chance that high security installations = will=20 have the audit system in immutable mode. For rules that do not resolve all the way to an inode, they could be put = on a=20 wait list that gets checked for resolution anytime mount is called. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro Subject: Re: Question about setting watches in auto-mounted directories in RHEL 5.2 Date: Sun, 30 Nov 2008 12:17:23 -0500 Message-ID: <20081130171653.GD14693@file.rdu.redhat.com> References: <200811300915.52390.sgrubb@redhat.com> <20081130151040.GC14693@file.rdu.redhat.com> <200811301047.07796.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200811301047.07796.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Taylor_Tad@emc.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Sun, Nov 30, 2008 at 10:47:07AM -0500, Steve Grubb wrote: > On Sunday 30 November 2008 10:11:10 Alexander Viro wrote: > > > > Unfortunately, auto-mounts are, well, automatic, so there's no one to > > > > issue that command. > > > > You do realize that they are, in the end, done from userland? ?Which is > > the natural place to do that... > > The problem is that's a little racy. But more importantly, it would be nice to > load rules once since there is a chance that high security installations will > have the audit system in immutable mode. > > For rules that do not resolve all the way to an inode, they could be put on a > wait list that gets checked for resolution anytime mount is called. Races are not hard to deal with - you mount on temporary directory, mark equivalent and mount --move to final destination. autofs daemon could do that just fine. As for the "anytime mount is called"... What are you going to do with the rules that *do* resolve to destination (subtree ones)? And to deal with the same races you'd have to do highly unpleasant things. In principle, it is possible. We hold i_mutex on the mountpoint and there is a moment just before grabbing vfsmount_lock when we know that we won't be backing off. That's when we are about to make the changes visible and locking conditions at that point are not quite unbearably bad. They *are* quite bad, though. There are three parts of that fun: * audit_filter_mutex needs to be held. Not a problem. * ->inotify_mutex is taken inside ->i_mutex that way. Not a problem, we already have that situation. * the real bitch: we really, REALLY can not do pathname resolution of any kind while we are in that area. kern_path() is a non-starter. That's where the PITA starts. Initial part is simple - we already know where and what we are going to attach, so unlike the case of MAKE_EQUIV handling we do not need to bother resolving those pathnames. However, the rest sucks hard enough to excavate decency from a politician. We need to decide which rules to extend. And doing _that_ accurately takes pathname resolution. Without it... well, the best proxy would be to see which rules cover a counterpart of mountpoint in some mounted instance of filesystem containing. Translation: we'll be getting false positives until audit_trim_trees() could be run. And we *can't* run it synchronously until we at least drop namespace_sem.