3:04 p.m.
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!
12:30 p.m.
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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--
Peter Moody Google 1.650.253.7306
Security Engineer pgp:0xC3410038
1:06 p.m.
On Mon, Oct 8, 2012 at 10:30 AM, Peter Moody <pmoody(a)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)?
4457
days inactive
4461
days old
linux-audit@lists.linux-audit.osci.io
2 comments
2 participants
participants (2)
-
Mark Moseley -
Peter Moody