Re: logging setuid changes

[Matt Provost <mprovost_(_at_)_termcap_(_dot_)_net>]

On May 10 11:35 PM, Julian Smith wrote:
> On Mon, 10 May 2004 14:57:11 -0700
> Matt Provost <mprovost_(_at_)_termcap_(_dot_)_net> wrote:
> 
> > I started playing around with having the kernel log setuid changes a
> > while ago, mostly out of frustration with the noise my box makes at
> > 1:30am every night as it runs a find on all the filesystems.
> > 
> > I wrote a little patch to the chmod system call that writes a message to
> > syslog every time someone adds the setuid bit to a file. I spent a while
> > messing around with the name cache to see if I could get it to print out
> > the pathname but gave up and have it printing the inode number and
> > filesystem. This way you can at least just `find -inum xxx /fs` and find
> > the file. It wouldn't be hard to rewrite /etc/security to handle that,
> > but I'd rather spend the time and get it right. I just wanted to get
> > some feedback on whether this was a good idea at all before I waste too
> > much more time.
> > 
> > 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
> 
> -- 
> http://www.op59.net

Your solution sounds a lot like BSM for Solaris, which I used several
years ago. I'd think if you were going to start tracing lots and lots of
syscalls it would make sense to implement something more general than
just modifying every single syscall. I know I used to audit execve calls
on Solaris which was cool but I never actually needed the logs.

This was just a specific instance where /etc/security already audits for
setuid/setgid files so I thought it made more sense to intercept the
call and log directly.

Matt