[RFC] linux-2.6.10-auditfs-tc1.patch

[Timothy R. Chavez]

Hello,

Attached to this e-mail is my first iteration of the file system
auditing piece needed for CAPP EAL4.  I appreciate all feedback, but
please read the TODO list prior to sending me feedback on something
I'm already aware of.  I've not stressed tested this code nor have I
done any formal FVT.  The testing I have done has been.. minimal. 
I've mostly seen if given scenarios work (move one watched file to
another watched location, create a hardlink to /etc/passwd from
/home/me, etc).

At this time, I'm unable to provide you with the userspace patch I
wrote, but encourage someone on this list to add the functionality to
libaudit/auditctl and submit the patch (Steve :)?).  If you'd like my
"guidance" please e-mail me privately.

ABOUT:

Thus far, the patch being submitted with this e-mail implements a
rudimentary file system auditing capability using the in-kernel audit
subsystem.  From userspace, an administrator passes into the kernel a
pathname and filterkey pair.  The terminating file or directory does
not have to exist at the time a watch point is created for it, but
it's parent does.

If at any point the parent is destroyed, auditing information for its
children is lost.  Likewise, if we mount over watched paths, we lose
auditing information, until we unmount.  Currently, there is no
decision on whether or not we ought to give the audit subsystem the
capability of dynamically remapping watch paths onto new mounts or
supporting theoretical watch paths where watch paths are arbitrary and
if they should come into existence within the filesystem, they become
watched and thus auditable.  Also, if I remember my code correctly, if
you move out of a watch path into a path that is not being watched,
your watch field is still pointing in a watch list, and will be
audited.  If you destroy this file or directory and recreate it in the
same (unwatched) path, it will no longer be audited.  I think I need
to add a field to the watch where we can enable/disable this behavior
per watch entry.

Provided both syscall auditing and file system auditing are both
configured and enabled, when a syscall of interest accesses a file or
directory being watched, it collects information about that file or
directory (via it's inode and watch entry) and adds it to the
audit_context of that syscall.  When the syscall exits, any files or
directory information collected is sent to userspace to be logged.

TODOs:

* Add RCU locking in the appropriate places to make SMP-safe
* Switch over to slab caches for struct audit_data, struct audit_file,
and struct audit_watch
* Think about how I can make it so an administrator can say, "Watch
this file only on the syscall open where uid=0" -- As of right now, if
filesystem auditing is on, every syscall (being audited) that accesses
a watched file or directory collects information about it and
generates a record.  Is this sufficient?
* Make it so filesystem auditing can be dynamically enabled/disabled
from userspace, rather then being "enabled" if configured or
"disabled" if not configured at boot time.
* Add/remove unnecessary information about the file or directory being
collected in the audit context.  Input on this?

-- 
- Timothy R. Chavez
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-2.6.10-auditfs-tc1.patch
Type: text/x-patch
Size: 26032 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050119/8768ab50/attachment.bin>