7:55 p.m.
Hello,
Here is the patch that adds new functionality to the audit-0.6.9 as well as
changes some old. Patched against audit-0.6.9.
CHANGELOG
+ The major addition is the ability to "list" watches on a given directory.
-> Added AUDIT_WATCH_LST macro
+ Defined new -L option
-> Added a new "watch" field to the audit_reply struct
-> Added new function audit_list_watches() to libaudit
-> Added support for watch listing in auditctl
+ Gave ability for auditctl to receive AUDIT_WATCH_ERR messages
-> Made it so the kernel could send AUDIT_WATCH_ERR messages regarding
AUDIT_WATCH_INS/REM/LST in the same fashion.
+ Changed types in libaudit to be identical to the types of audit_watch in
audit.h
--
-tim
8:50 a.m.
On Monday 28 March 2005 20:55, Timothy R. Chavez wrote:
-> Added support for watch listing in auditctl
I'm happy we have something. However, we never finished the discussion from
yesterday. I don't think you should have to pass a path to list the watches.
Let's just walk the watch list and dump the strings. Maybe what you are
thinking of is a watch status command? Pass a path and it tells you what
device and namespace its bound to. But I'm just guessing since we need to
finish the questions I posed yesterday:
1) Can you explicitly state the namespace or device when you load a watch?
2) Does the device and namespace get implicitly bound to the path by virtue
of who loaded the watch and the mount table that in effect at the time the
rule was loaded?
3) Does the watch work for all name spaces and devices?
These topics need to be documented for the man page.
+ Changed types in libaudit to be identical to the types of
audit_watch in
audit.h
I'll readjust the types to userspace types. __u32 is kernel. uint32_t is
userspace.
Thanks,
-Steve
9:45 a.m.
On Tue, 2005-03-29 at 09:50 -0500, Steve Grubb wrote:
I'll readjust the types to userspace types. __u32 is kernel.
uint32_t
is userspace.
We can use uint32_t in kernel too. The only reason for using __u32 in
the kernel is for when structure definitions are shared with userspace
and we want to to avoid the requirement for C99 types in legacy
applications which use POSIX APIs. We don't need to worry about that
here so we should use uint32_t throughout.
--
dwmw2
9:55 a.m.
On Tuesday 29 March 2005 08:50 am, Steve Grubb wrote:
On Monday 28 March 2005 20:55, Timothy R. Chavez wrote:
> -> Added support for watch listing in auditctl
I'm happy we have something. However, we never finished the discussion from
yesterday. I don't think you should have to pass a path to list the
watches. Let's just walk the watch list and dump the strings. Maybe what
you are thinking of is a watch status command? Pass a path and it tells you
what device and namespace its bound to. But I'm just guessing since we need
to finish the questions I posed yesterday:
Sorry, I went to a Jon "Maddog" Hall presentation on Economics & Open Source
-- good stuff. I tried to explain to you why I felt it wouldn't be a good
idea to just dump the strings. What you'd get right now is something like:
'name=foo, filterkey=fk_foo, permissions=15'
To me, this isn't that informative, because you have no idea where 'foo' is.
I mean, I can add this, if this is what you want -- it can use the same
master list that the "remove all" feature will eventually use. However, no
plans for this in the near near future (week) -- must get to linux-fsdevel.
1) Can you explicitly state the namespace or device when you load a watch?
No, this is implied by the path you specify.
2) Does the device and namespace get implicitly bound to the path by virtue
of who loaded the watch and the mount table that in effect at the time the
rule was loaded?
Yes.
3) Does the watch work for all name spaces and devices?
All namespaces: Yes. Same inode no matter which view of the file system
you're using.
All devices: No. Different devices, different inodes. Thus, we may not mount
over a watched path and expect a remapping of watches on top of it. Why?
These aren't the same objects that the administrator targetted for audit (and
plus, it'd be really hard to do with the current design ;-)).
These topics need to be documented for the man page.
> + Changed types in libaudit to be identical to the types of audit_watch
> in audit.h
I'll readjust the types to userspace types. __u32 is kernel. uint32_t is
userspace.
Alright.
Thanks,
-Steve
-tim
10:46 a.m.
On Tuesday 29 March 2005 10:55, Timothy R. Chavez wrote:
I tried to explain to you why I felt it wouldn't be a good
idea to just dump the strings. What you'd get right now is something like:
'name=foo, filterkey=fk_foo, permissions=15'
I think this is good enough. It should be returned in a structure. That's what
rules does. Userspace interprets the structure and prints it. Let's reuse
current structures instead of making new ones.
To me, this isn't that informative, because you have no idea
where 'foo'
is. I mean, I can add this, if this is what you want
But since you have "name=foo", you could also go ahead and look up that path
and return the additional data that you were wanting to return. This needs to
be real simple (from the user's perspective) to be effective.
-- it can use the
same master list that the "remove all" feature will eventually use.
You don't need a remove all. This can be done in userspace just like the
rules. I get the list and bounce it back with a remove. Let's keep it simple.
-Steve
7197
days inactive
7197
days old
linux-audit@lists.linux-audit.osci.io
4 comments
3 participants
participants (3)
-
David Woodhouse -
Steve Grubb -
Timothy R. Chavez