Re: auditd design decision

On Sat, 8 Jan 2005 10:53:05 -0800 (PST), Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: Oh, Casey. I guess I should have provided more context to what I was actually doing. We're already aware of the problem you've just described and I've been working on both the userspace and kernel implementation of a solution. Hopefully by the end of next week (I'm going to be in an SELinux class for 3 days) I'll have out to this list, the kernel code that compliments the userspace code I was speaking of (although there is a good chance I'll be unable to release the userspace code until IBM is approved to do such things). The userspace interface into the kernel's audit subsystem simple provides a path ending with the filename/directory we wish to audit (I don't believe we're dealing with devices (at least not yet)). Insert <some kernel magic here> and the inode of the file/dir we wish to watch and its parent's inode have all the necessary information. You'll see the patch. What's better for an upstream solution? Obstrusive hooks in core VFS functions or the inconvience of the admin having to restart auditd (or I guess, reload the watch list from auditctl)? Klaus might be able to make this call. So far we've been fairly quiet on what we really want to do with mounting. I'm pretty sure mount --binds are taking care of with the current implementation (that I'm working on). I'm not sure we want the audit subsystem to be dynamic like this and adapt to such changes.. it could add some unappealing complexity. As far as "movement" outside of a watched location, we're not going to audit. If we're only interested in /etc/passwd and we move /etc/passwd to /tmp/passwd (we're presumably the administrator), /etc/passwd no longer exists and we will not receive records for any accesses on /tmp/passwd (unless /tmp/passwd is a watched location (object) itself). When /etc/passwd exists again or the inode associated with /etc/passwd still exists, generating audit records for /etc/passwd is still possible. When creating a hard link to /etc/passwd from /home/user/bypass, you're right, we don't want a bypass of the audit subsystem. Because our information is associated with the inode, however, and we can't hard link across devices, we still get audit records. For other cases, to know if a file/dir is being watched, it consults its parent (two hooks in dcache). If its parent's i_audit field is NULL, its watchlist is empty (depending on how I decide to handle removal of watches), or the file/dir is not in the watchlist, we're not being watched, otherwise we are, and we point ourselves at our watch entry in the watchlist. When we hit permission() in fs/namei, if we are not NULL, we're being watched and we add ourselves into the audit_context of the current task via a hook. If the current task has a rule stating interest in what file system objects its accessing, it will generate logs for them upon exit. All other filtering, if any, of file system objects will be handled in userspace. Matching syscall with file system object can be done with serial numbers. Neither. It was a crappy Maple glazed donut from H.E.B (a regional grocery story here in Texas) I think it'd be easy for the time being to insert watch points at auditd start up and remove watch points at auditd shut down. Or if you prefer not to add code to auditd, we can do something like: Insert watch points: ./auditctl -W watch.list Remove watch points: ./auditctl -w watch.list -- - Timothy R. Chavez