Question about setting watches in auto-mounted directories in RHEL 5.2

Question about setting watches in auto-mounted directories in RHEL 5.2

[Taylor_Tad]

[-- Attachment #1.1: Type: text/plain, Size: 824 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 2665 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Question about setting watches in auto-mounted directories in RHEL 5.2

[Steve Grubb]

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

Re: Question about setting watches in auto-mounted directories in RHEL 5.2

[Alexander Viro]

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...

Re: Question about setting watches in auto-mounted directories in RHEL 5.2

[Steve Grubb]

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.

-Steve

Re: Question about setting watches in auto-mounted directories in RHEL 5.2

[Alexander Viro]

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.