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. On Thu, Oct 4, 2012 at 1:04 PM, Mark Moseley <[email protected]> wrote: > Hi. Didn't realize this was a closed list till I started wondering why > the automated invite hadn't shown up :) > > Just a quick question: I'm working on parsing audit logs and I noticed > one oddity. If a chown or chmod is done recursively on a directory > (and I imagine there are other examples than chown/chmod) done from > somewhere outside the affected directory, in the audit log entries for > the *files* within those directories, there's no way to track back > what directory the files live in. > > Example: > > >From /tmp, doing a "chown -R 0 /home/moseley/tmp/tmp/", where the > contents of /home/moseley/tmp/tmp/ are two files, 'a' and 'b' (I've > added spacing to make it more readable): > > type=SYSCALL msg=audit(1349375745.138:4143): arch=c000003e syscall=260 > success=yes exit=0 a0=4 a1=77a988 a2=0 a3=ffffffff items=1 ppid=5775 > pid=19589 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts13 ses=3387 comm="chown" exe="/bin/chown" key=(null) > type=CWD msg=audit(1349375745.138:4143): cwd="/tmp" > type=PATH msg=audit(1349375745.138:4143): item=0 name="b" > inode=2367514 dev=08:02 mode=0100664 ouid=1000 ogid=1000 rdev=00:00 > --- > type=SYSCALL msg=audit(1349375745.138:4144): arch=c000003e syscall=260 > success=yes exit=0 a0=4 a1=782b08 a2=0 a3=ffffffff items=1 ppid=5775 > pid=19589 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=pts13 ses=3387 comm="chown" exe="/bin/chown" key=(null) > type=CWD msg=audit(1349375745.138:4144): cwd="/tmp" > type=PATH msg=audit(1349375745.138:4144): item=0 name="a" > inode=2367514 dev=08:02 mode=0100664 ouid=0 ogid=1000 rdev=00:00 > --- > type=SYSCALL msg=audit(1349375745.138:4145): arch=c000003e syscall=260 > success=yes exit=0 a0=ffffffffffffff9c a1=779520 a2=0 a3=ffffffff > items=1 ppid=5775 pid=19589 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 > egid=0 sgid=0 fsgid=0 tty=pts13 ses=3387 comm="chown" exe="/bin/chown" > key=(null) > type=CWD msg=audit(1349375745.138:4145): cwd="/tmp" > type=PATH msg=audit(1349375745.138:4145): item=0 > name="/home/moseley/tmp/tmp/" inode=2367031 dev=08:02 mode=040775 > ouid=1000 ogid=1000 rdev=00:00 > > > In the first two entries, there's no indication that 'a' or 'b' live > in /home/moseley/tmp/tmp/. > > In the case of a non-relative chown/chmod (e.g. chown'ing > /home/moseley/tmp/tmp/a), the 'item=0' line has the full pathname to > /home/moseley/tmp/tmp/a in its entry. > > My question is, is there anything in these entries that I might be > missing that ties the first two back to the 3rd? I'm building a > tracking system for 'changed/written' files, so I change all 'item' > pathnames into absolute pathnames, but in this case, I'm at a loss as > to how to (programmatically) tie them together, beyond "pid". Or > better yet, is there some flag in the first two entries that I might > be missing that shows that they're 'children' of the third entry. > > I'm not crazy about the idea of building some of state into my parsing > (i.e. I see a relative chown/chmod 'item' entry, so stash these and > keep watching for chown/chmod's with the same PID) but if that's my > only option, then that's my only option. But I figured I'd ask to see > if there was something far more clever than I'm missing (possibly in > plain sight). > > Thanks! > > -- > Linux-audit mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-audit -- Peter Moody Google 1.650.253.7306 Security Engineer pgp:0xC3410038 -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
