Re: logging setuid changes

[William Ahern <william_(_at_)_25thandClement_(_dot_)_com>]

On Mon, May 10, 2004 at 11:35:37PM +0100, Julian Smith wrote:
> On Mon, 10 May 2004 14:57:11 -0700
> Matt Provost <mprovost_(_at_)_termcap_(_dot_)_net> wrote:
<snip>
> > Some things to do that I have in mind:
> > -add to fchmod (easy)
> > -wrap in a sysctl so you can turn it off and on
> > -print out different warnings (no warning?) if the fs is mounted
> > nosuid/noexec
> > -try and get the pathname out of the kernel name cache if possible, a la
> > lsof
> > -setgid?
> 
> I tried a similar thing a couple of years ago, modifying the
> kernel's open and rename functions so that they wrote filenames of
> modified/renamed files to syslog. It worked fine, though these days I
> run with $LD_PRELOAD set to find a user-land library that intercepts
> file operations, to save modifying the kernel every 6 months.
> 
> There are a lot of really interesting things one can do if alterations
> to files are made visible, so I'd be really interested in doing this
> sort of thing properly with a sysctl etc.
> 
> - Julian

Last year I was working on a userland utility to watch the filesystem:

	http://www.25thandclement.com/~william/projects/watch.html

watch is broken in some corner cases, but the real impediment is the open
file limit. If the VFS could keep track of parent directories then a new
kqueue vnode filter event could be added: NOTE_DMODIFY (similar to Linux's
DNOTIFY). This way only directories would need to be opened, so the
descriptor limit wouldn't be as prohibitive for large filesystems.
Alternatively, watch could just be fixed for the corner cases and it should
be able to handle /usr/bin and /usr/sbin and other smallish directories.

FWIW, with my watch utility you could get Matt's patch's behavior in
userland with something like:

	watch /usr/bin /usr/sbin | awk '{print $2}' | while read FILE; do
		if [ -u $FILE ];
			echo "Modified file with setuid bit set"
		fi
	done

watch will write to stdout events like so:

	+ /path/to/new/file
	- /path/to/deleted/file
	! /path/to/modified/file

I know for sure that watch is broken in the case where a particular filename
is deleted and created in succession and the inode remains the same. If the
file is a directory then watch will fail to descend into it to again. The
assumption was that children would always be deleted--and their events
fired--before parents, but somehow tar/pax manages to otherwise.

- Bill