Recursive chown/chmod not showing enclosing directory

[Peter Moody]

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 <moseleymark at gmail.com> 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
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit



-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038