Recursive chown/chmod not showing enclosing directory

[Mark Moseley]

On Mon, Oct 8, 2012 at 10:30 AM, Peter Moody <pmoody at google.com> wrote:
> What are the actual audit rule(s) you have installed?
>
> The way we do it is to key the rules with something descriptive like
>
> -a exit,always -F arch=b64 -S chmod -S fchmod -S fchmodat -k success=1
> -F dir=/home/mosley/tmp -k home_moseley_tmp_chown
>
> so then your logs will have key="home_mosely_tmp_home_chown" and
> you'll know exactly where the chown'd file lives.


Just two rules currently:

-a always,exit -F success=1 -F perm=wa -F dir=/home/moseley/tmp
-a always,exit -F success=1 -S chroot -F dir=/home/moseley/tmp

But I should point out that this is just for dev work. The real system
would be on a web hosting platform and would be getting audit entries
for literally millions different subdirectories, so labeling via a key
wouldn't be possible. Though I do like the idea of a key as a flag for
my code to match directories at a top-level.

I'm obviously biased here but it seems like it'd be better to log the
full pathname in the audit logs in the recursive case (and chroot'd
case -- see below). Unless I'm calling ausearch wrong, this even
evades tools like ausearch, e.g.

# chmod -R a+r /home/moseley/tmp/mydir/
# ausearch -f /home/moseley/tmp/

only find:

time->Mon Oct  8 10:45:25 2012
type=PATH msg=audit(1349718325.699:1206): item=0
name="/home/moseley/tmp/mydir/" inode=2623763 dev=08:02 mode=040755
ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1349718325.699:1206):  cwd="/"
type=SYSCALL msg=audit(1349718325.699:1206): arch=c000003e syscall=268
success=yes exit=0 a0=ffffffffffffff9c a1=20620f0 a2=1ed
a3=7fff0817e3f0 items=1 ppid=15417 pid=15457 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=1157 comm="chmod"
exe="/bin/chmod" key=(null)

ausearch finds the directory's entry but not the file's. You could
make the argument that someone using tools like ausearch for security
analysis could be missing important info (though again, I could be
missing some flags/setting).

I noticed too while working on this that audit entries in a chroot
context get logged like they're in the chroot context, i.e. in my dev
example, if I'd chrooted to /home/moseley/tmp and created a file
called 'myfile' in /home/moseley/tmp/mydir, it'd get logged in the
audit logs as /mydir/myfile, not /home/moseley/tmp/mydir/myfile. Seems
like that'd also be something easily miss-able by any utilities
expecting full pathnames and that it'd be better to have the full
pathnames in the audit log entries.

Anyone know of any other cases where an entry doesn't contain a
pathname that's reconstructable from the entry alone (i.e. either a
full pathname in an item, or the enclosing directory in one of the
items, or just assuming it's relative to the 'cwd' from the cwd line)?