11:05 a.m.
Hello,
1. LIST WATCHES
I'm just finishing up the "list watches" feature and I have a question.
With
the current design, there is no way to tell the kernel, "give me a list of
all watches". Currently, a watch is a structure with these fields:
name : the name of dentry->d_name that's to be watched
filterkey : an arbitrary string no greater then 32 bytes (including
terminating \0)
perms : permissions filter
Thus you really wouldn't know the location of these watches. So, perhaps I
could add a 'path' field which just kept the path I specified when the watch
was inserted. But, this too might be misleading (if we are to every change
namespaces) or the administrator uses a relative path. We technically do
support relative paths when inserting/removing a watch (even though auditctl
warns otherwise). Furthermore, would this look bad when trying to sell this
to fsdevel or LKML?
So, the compromise I came up with is to add an option to auditctl, '-L' which
would allow the admin to check the watches on a given path. I think this
fits decently with the idea behind this feature: to help the administrator
remember what watches they set. So now, it looks like this:
./auditctl -w /audit/foo
./auditctl -w /audit/bar
./auditctl -L /audit
AUDIT_WATCH : LIST : /audit/foo
AUDIT_WATCH : LIST : /audit/bar
I'm working on getting the entire struct exported to userspace so we can also
say something about the perms filter and filterkey.
2. HOOKS
So I've been experimenting around and have hooks capturing what I think is
required by CAPP. Klaus, when this patch is released we REALLY need your
input and appraisal. One of the problems we face here is that "access" can
generate multiple records and for some reason it feels like the administrator
would have to have some sort of knowledge of what's going on in the kernel
that extends past intuition. For this reason, I feel like perhaps I should
have another field that provides some sort of context to the record. So for
instance, if the record was generated from a permissions function, we'd set
the "context" field to show that. Is this a good idea?
When I post the patch, I'll post it with a list of hooks and what each does.
-tim
11:13 a.m.
On Monday 28 March 2005 11:05 am, Timothy R. Chavez wrote:
Hello,
1. LIST WATCHES
I'm just finishing up the "list watches" feature and I have a question.
With the current design, there is no way to tell the kernel, "give me a
list of all watches". Currently, a watch is a structure with these fields:
name : the name of dentry->d_name that's to be watched
filterkey : an arbitrary string no greater then 32 bytes (including
terminating \0)
perms : permissions filter
Thus you really wouldn't know the location of these watches. So, perhaps I
could add a 'path' field which just kept the path I specified when the
watch was inserted. But, this too might be misleading (if we are to every
change namespaces) or the administrator uses a relative path. We
technically do support relative paths when inserting/removing a watch (even
though auditctl warns otherwise). Furthermore, would this look bad when
trying to sell this to fsdevel or LKML?
So, the compromise I came up with is to add an option to auditctl, '-L'
which would allow the admin to check the watches on a given path. I think
this fits decently with the idea behind this feature: to help the
administrator remember what watches they set. So now, it looks like this:
./auditctl -w /audit/foo
./auditctl -w /audit/bar
./auditctl -L /audit
AUDIT_WATCH : LIST : /audit/foo
AUDIT_WATCH : LIST : /audit/bar
I'm working on getting the entire struct exported to userspace so we can
also say something about the perms filter and filterkey.
2. HOOKS
So I've been experimenting around and have hooks capturing what I think is
required by CAPP. Klaus, when this patch is released we REALLY need your
input and appraisal. One of the problems we face here is that "access" can
generate multiple records and for some reason it feels like the
administrator would have to have some sort of knowledge of what's going on
in the kernel that extends past intuition. For this reason, I feel like
perhaps I should have another field that provides some sort of context to
the record. So for instance, if the record was generated from a
permissions function, we'd set the "context" field to show that. Is this
a good idea?
When I post the patch, I'll post it with a list of hooks and what each
does.
3. DELETE ALL WATCHES
This is something I was asked about last week because it'd be useful for the
test team. This should be relatively trivial to implement as a global linked
list to all the watches. I don't care about their locations in the
filesystem, just that I can unlink them from their watchlists and put back
all references so that they can be properly freed. This will come later,
after the next patch is out, because I really do need to get this...
<exhibits self-control>... "darn thing", out.
-tim
11:34 a.m.
From Tim:
3. DELETE ALL WATCHES
This is something I was asked about last week because it'd be useful for
the
test team. This should be relatively trivial to implement as a global
linked
list to all the watches. I don't care about their locations in
the
filesystem, just that I can unlink them from their watchlists and put back
all references so that they can be properly freed. This will come
later,
after the next patch is out, because I really do need to get this...
<exhibits self-control>... "darn thing", out.
This may be useful for us (the test team), but I don't want to see
something implemented just for the sake of test. Is this something
useful for the real world? It sounds a bit dangerous to me.
Kris Wilson
Linux Security
(512) 838-0126 T/L:678-0126
krisw(a)us.ibm.com
12:53 p.m.
On Monday 28 March 2005 12:34, Kris Wilson wrote:
Is this something useful for the real world?
Sort of. Suppose you want to do a service audit restart, the normal expected
behavior is to restart the daemon, reset the in-kernel rules, load the new
rules. This is how iptables works.
-Steve
11:55 a.m.
On Monday 28 March 2005 11:29 am, Steve Grubb wrote:
On Monday 28 March 2005 12:05, Timothy R. Chavez wrote:
> Thus you really wouldn't know the location of these watches.
I prefer keeping it simple. Just dump the whole list. This is how the list
rules works. Besides,
Right, but list rules is fundamentally different then the watch list stuff.
Trying to make it "all fit" might make it look rather sloppy and give us
misinformation. Technically speaking, the watches are disseminated all over
an entire filesystem and they appear on different devices and namespaces.
What makes a watch is two part, it's location, and what's at that location.
If we dump back a "global" list simply with the paths we used to add the
watch and we have,
"/usr/this_file_is_watched"..
How do we know this is accurate?
What if we changed the /usr device by mounting over it after we inserted the
watch and we then forgetfully say to ourselves, "Oh we have a watch
at /usr/this_file_is_watched" and then we try to remove it, but to no avail;
the watch doesn't trully exist here (ie: we can't get to it from this path
currently). This information is not trustworthy.
Even if we could do a d_path() on the dentry that holds the watch (this would
require that we save the dentry on the watch), this might not give us ALL the
information we need. I think it's easy enough for the admin to go, "Oh hm, I
wonder if I added a watch here, let me check" -- The down side is if they
wanted the global list of all watches (they can get at):
find / -type d -exec auditctl -L {} ";"
would be the way to do that -- this would take a great ammount of time (but
would be most accurate).
audit -L | grep '^\/tmp'
should get the ones on tmp.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
-tim
12:59 p.m.
On Monday 28 March 2005 12:55, Timothy R. Chavez wrote:
The down side is if they wanted the global list of all watches (they
can get
at):
find / -type d -exec auditctl -L {} ";"
would be the way to do that -- this would take a great ammount of time (but
would be most accurate).
What happened to all those text strings that auditctl sent into the kernel to
setup the watches? Did they get discarded? It seems to me that they should
still be around and on a list of some kind.
-Steve
1:50 p.m.
On Monday 28 March 2005 12:59 pm, Steve Grubb wrote:
On Monday 28 March 2005 12:55, Timothy R. Chavez wrote:
> The down side is if they wanted the global list of all watches (they can
> get at):
>
> find / -type d -exec auditctl -L {} ";"
>
> would be the way to do that -- this would take a great ammount of time
> (but would be most accurate).
What happened to all those text strings that auditctl sent into the kernel
to setup the watches? Did they get discarded? It seems to me that they
should still be around and on a list of some kind.
Hm? The watch.name we pass into the kernel is a <path> to the watch point.
We use it to walk the filesystem up to the parent of the watch point. The
watch that is added into the filesystem has a watch->name eq "terminating
file/dir name of <path>" -- We can only assume <path> is relevant for
this
walk for the reasons I mentioned in my prior e-mail.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
-tim
2:31 p.m.
On Monday 28 March 2005 14:50, Timothy R. Chavez wrote:
We can only assume <path> is relevant for this
walk for the reasons I mentioned in my prior e-mail.
I still don't see the problem why you can't dump the watches like the rules
are done. If you have the strings, why can't you dump them back?
-Steve
2:34 p.m.
On Monday 28 March 2005 02:31 pm, Steve Grubb wrote:
On Monday 28 March 2005 14:50, Timothy R. Chavez wrote:
> We can only assume <path> is relevant for this
> walk for the reasons I mentioned in my prior e-mail.
I still don't see the problem why you can't dump the watches like the rules
are done. If you have the strings, why can't you dump them back?
What good would dumping the watch information be if you don't know where the
watch trully is in the filesystem? Shouldn't that also be important?
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
-tim
3:57 p.m.
On Monday 28 March 2005 15:34, Timothy R. Chavez wrote:
What good would dumping the watch information be if you don't
know where
the watch trully is in the filesystem?
So that you can delete it or see what is supposed to be in-kernel.
Shouldn't that also be important?
Yes and no. The reason you dump the list is to confirm that watches were
loaded, or to jog your memory as you delete one, or maybe you want to see if
a watch already exists before you add another. You also might dump a list in
troubleshooting to see why an audit event isn't being detected. In all cases
you at least want the information that was sent into the kernel.
Can you explicitly state the namespace or device when you load a watch? Or
does the device and namespace get implicitly bound to the path by virtue of
who loaded the watch and at what time? Or does the watch work for all name
spaces and devices? (This topic needs to be documented for the man page.)
If there's an implicit binding, I can see why you might want that info during
troubleshooting. But its not the same as getting a list for the purpose of
deleting one.
-Steve
7208
days inactive
7208
days old
linux-audit@lists.linux-audit.osci.io
10 comments
3 participants
participants (3)
-
Kris Wilson -
Steve Grubb -
Timothy R. Chavez