11:52 a.m.
Hello,
I've been taking a look at the auditfs code in U2, and I've noticed an
issue with the path-based watching. In U2, the path-based watching
code only keeps tabs on the parent of given user watch, instead of
watching the entire path back to the filesystem root.
This means that if a path component beyond the user watch's parent
changes, the recreation of the object at the watched path will not be
caught. Any subsequent events on the object at the watched path will
also not be caught.
For example:
# auditctl -w /one/two/three/four
# mkdir -p /one/two/three
# :> /one/two/three/four
# echo "hello world" > /one/two/three/four
<audit records generated>
# mv /one/two /one/too
# mkdir -p /one/two/three
# :> /one/two/three/four
# echo "hello world" > /one/two/three/four
<no audit records generated>
Is this a known limitation?
Amy
3:39 p.m.
Hi David,
David Woodhouse wrote: [Tue Aug 16 2005, 01:48:20PM EDT]
On Tue, 2005-08-16 at 12:52 -0400, Amy Griffis wrote:
> Is this a known limitation?
Yes. The watch follows the parent directory if it's renamed.
I believe you mean that inode-based watching catches events on the
watched file at the new path. But the point of path-based watching is
to watch a particular location. With the current implementation,
there are ways to miss events at the specified location.
Amy
4:19 p.m.
On Tuesday 16 August 2005 16:39, Amy Griffis wrote:
But the point of path-based watching is to watch a particular
location.
I would agree with this. If the admin wanted to watch a specific
path/file...it should honor it. To move the file is really renaming the file.
But the watch is still desired. In practice, though, it doesn't cause
problems. I don't know of any trusted app that renames a directory and
creates a new data file. There could be user defined watches that might have
problems with the current behavior, though.
There is also no way to specify that you want to watch a file on an unmounted
partition or non-existing directory. Just thought I'd bring this up too. Not
really needed, though.
-Steve
6:50 p.m.
On Tue, 16 Aug 2005 17:19:06 EDT, Steve Grubb said:
There is also no way to specify that you want to watch a file on an
unmounted
partition or non-existing directory. Just thought I'd bring this up too. Not
really needed, though.
Is the intent that the automounter/whatever would add the watches when the
partition gets mounted? (Yes, I know there's *other* issues when you're
mounting a user-supplied medium such as a cdrom/zip/flash...)
6:05 a.m.
On Tuesday 16 August 2005 19:50, Valdis.Kletnieks(a)vt.edu wrote:
Is the intent that the automounter/whatever would add the watches
when the
partition gets mounted?
Not that I know of. I was just pointing out another limitation for
completeness. I have been thinking a little about having dynamically
triggered rulesets. Its probably too racy to be reliable.
-Steve
11:31 a.m.
On Tue, Aug 16, 2005 at 05:19:06PM -0400, Steve Grubb wrote:
In practice, though, it doesn't cause problems. I don't know
of any
trusted app that renames a directory and creates a new data file.
If we aren't trying to watch all path components, I don't understand
why we need the dcache hooks.
If we want to watch a particular dentry, it seems like watching its
parent's inode for filesystem events would suffice. An inode is
always held by the i_sem through the execution of any event-catching
hook. Thus we are able to add a watch for the inode appearing
at the watched location in time to catch any further events.
I've read through quite a bit of the archives for this list, and
haven't found the reason for the dcache hooks. Could someone comment
on this?
Thanks,
Amy
12:10 p.m.
On Thursday 18 August 2005 11:31, Amy Griffis wrote:
On Tue, Aug 16, 2005 at 05:19:06PM -0400, Steve Grubb wrote:
> In practice, though, it doesn't cause problems. I don't know of any
> trusted app that renames a directory and creates a new data file.
If we aren't trying to watch all path components, I don't understand
why we need the dcache hooks.
The dcache hooks are used to manage the watches after they've been
created. So let's say you've said,
watch /etc/shadow
When you then later decide to do,
passwd
During the execution of 'passwd', /etc/shadow will momentarily cease to exist.
When /etc/shadow comes back, it'll be a new inode. We must then update that
inode with the necessary watch information. Thus, the watch point,
"/etc/shadow" is preserved.
Using the same 'passwd' execution, we might also consider this scenario,
watch /etc/nshadow
During the execution of 'passwd', /etc/shadow will be renamed to
"nshadow".
If we have watched /etc/nshadow, then when the rename occurs, we add
the to the inode under /etc/nshadow, and thus, it becomes auditable.t
In this light, the feature does a decent job at auditing well-defined (and
hopefully security critical) locations and names.
If we want to watch a particular dentry, it seems like watching its
parent's inode for filesystem events would suffice.
We must rely both on the dentry and the inode. We're really watching the
inode, but the way we discover this inode, is through its dentry. So even if
this were the approach we took, it'd still need to use the dcache right?
An inode is
always held by the i_sem through the execution of any event-catching
hook. Thus we are able to add a watch for the inode appearing
at the watched location in time to catch any further events.
I've read through quite a bit of the archives for this list, and
haven't found the reason for the dcache hooks. Could someone comment
on this?
Hope this helps.
-tim
Thanks,
Amy
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
12:35 p.m.
On Thu, 2005-08-18 at 12:31 -0400, Amy Griffis wrote:
If we aren't trying to watch all path components, I don't
understand
why we need the dcache hooks.
If we want to watch a particular dentry, it seems like watching its
parent's inode for filesystem events would suffice. An inode is
always held by the i_sem through the execution of any event-catching
hook. Thus we are able to add a watch for the inode appearing
at the watched location in time to catch any further events.
I've read through quite a bit of the archives for this list, and
haven't found the reason for the dcache hooks. Could someone comment
on this?
To ensure that the audit state of the inode is set up properly before it
becomes accessible to another thread via the dcache (via __d_lookup).
--
Stephen Smalley
National Security Agency
5:51 p.m.
Stephen Smalley wrote: [Thu Aug 18 2005, 01:35:18PM EDT]
On Thu, 2005-08-18 at 12:31 -0400, Amy Griffis wrote:
> If we aren't trying to watch all path components, I don't understand
> why we need the dcache hooks.
>
> If we want to watch a particular dentry, it seems like watching its
> parent's inode for filesystem events would suffice. An inode is
> always held by the i_sem through the execution of any event-catching
> hook. Thus we are able to add a watch for the inode appearing
> at the watched location in time to catch any further events.
>
> I've read through quite a bit of the archives for this list, and
> haven't found the reason for the dcache hooks. Could someone comment
> on this?
To ensure that the audit state of the inode is set up properly before it
becomes accessible to another thread via the dcache (via __d_lookup).
Thanks, I see the potential race now.
4:09 p.m.
On Tuesday 16 August 2005 11:52, Amy Griffis wrote:
Hello,
I've been taking a look at the auditfs code in U2, and I've noticed an
issue with the path-based watching. In U2, the path-based watching
code only keeps tabs on the parent of given user watch, instead of
watching the entire path back to the filesystem root.
This means that if a path component beyond the user watch's parent
changes, the recreation of the object at the watched path will not be
caught. Any subsequent events on the object at the watched path will
also not be caught.
For example:
# auditctl -w /one/two/three/four
# mkdir -p /one/two/three
# :> /one/two/three/four
# echo "hello world" > /one/two/three/four
<audit records generated>
# mv /one/two /one/too
# mkdir -p /one/two/three
# :> /one/two/three/four
# echo "hello world" > /one/two/three/four
<no audit records generated>
Is this a known limitation?
It is known. In a CAPP environment, this sort of trickery will not come up.
To do what you want to do, the logic would get extremely complicated and
perhaps one day it'll be doable (upstream). Because we're storing the
information _in_ the file system we're limited on how much state we can
keep.
The original way we had planned on doing the logic was frowned upon
because it required a persisent (and potentially sizeable) map of a file
system depicting where all the watched locations are (and I believe
there were some namespace issues as well). This way each component
of the watched path in the actual file system could be mapped all the way
up to the root directory.
-tim
Amy
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
4:18 p.m.
On Tuesday 16 August 2005 16:09, Timothy R. Chavez wrote:
On Tuesday 16 August 2005 11:52, Amy Griffis wrote:
> Hello,
>
> I've been taking a look at the auditfs code in U2, and I've noticed an
> issue with the path-based watching. In U2, the path-based watching
> code only keeps tabs on the parent of given user watch, instead of
> watching the entire path back to the filesystem root.
>
> This means that if a path component beyond the user watch's parent
> changes, the recreation of the object at the watched path will not be
> caught. Any subsequent events on the object at the watched path will
> also not be caught.
>
> For example:
>
> # auditctl -w /one/two/three/four
> # mkdir -p /one/two/three
> # :> /one/two/three/four
> # echo "hello world" > /one/two/three/four
>
> <audit records generated>
>
> # mv /one/two /one/too
> # mkdir -p /one/two/three
> # :> /one/two/three/four
> # echo "hello world" > /one/two/three/four
>
> <no audit records generated>
>
> Is this a known limitation?
It is known. In a CAPP environment, this sort of trickery will not come up.
To do what you want to do, the logic would get extremely complicated and
perhaps one day it'll be doable (upstream). Because we're storing the
information _in_ the file system we're limited on how much state we can
keep.
The original way we had planned on doing the logic was frowned upon
because it required a persisent (and potentially sizeable) map of a file
system depicting where all the watched locations are (and I believe
there were some namespace issues as well). This way each component
of the watched path in the actual file system could be mapped all the way
up to the root directory.
Er... and provide a mechanism to keep state such that a watched location
is always watched when it exists regardless of any "inbetween" activity
that breaks the watched path and then reconstructs it.
-tim
-tim
>
> Amy
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
>
>
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
7065
days inactive
7067
days old
linux-audit@lists.linux-audit.osci.io
12 comments
8 participants
participants (8)
-
Amy Griffis -
Amy Griffis -
David Woodhouse -
Linda Knippers -
Stephen Smalley -
Steve Grubb -
Timothy R. Chavez -
Valdis.Kletnieks＠vt.edu