On Mon, Dec 12, 2011 at 6:40 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Sunday, December 11, 2011 02:09:27 PM Peter Moody wrote:
> This patch extends Eric's test patch from 11/17 (
>
http://www.redhat.com/archives/linux-audit/2011-November/msg00045.html).
> This turns -C into a long opt with similar syntax to -F.
Thanks.
> One strange thing related to this patch: auditd seems to be reporting
> success for a normal user process (gklrellm) opening /proc/meminfo (mode
> 444) O_RDWR, and I don't see how this is possible. eg:
>
> type=SYSCALL msg=audit(1323540255.146:97): arch=c000003e syscall=2
> success=yes exit=13 a0=4b1972 a1=0 a2=1b6 a3=0 items=1 ppid=1704 pid=1797
> auid=11532 uid=11532 gid=5000 euid=11532 suid=11532 fsuid=11532 egid=5000
> sgid=5000 fsgid=5000 tty=(none) ses=1 comm="gkrellm"
exe="/usr/bin/gkrellm"
> key="permissive"
> type=CWD msg=audit(1323540255.146:97): cwd="/home/pmoody"
> type=PATH msg=audit(1323540255.146:97): item=0 name="/proc/meminfo"
inode=
> 4026532008 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00
>
> hopefully someone with more auditd internal knowledge can explain what's
> going on.
Simple, int open(const char *pathname, int flags, mode_t mode);
So, we want to look at a1's contents.
d'oh, of course. I keep thinking it's a2 for some reason.
Its a zero. So, let's look that up in
/usr/include/asm-generic/fcntl.h:
#define O_RDONLY 00000000
#define O_WRONLY 00000001
#define O_RDWR 00000002
So, it would appear open is called with O_RDONLY, which is allowed by the
permissions 0444.
> auditctl -l doesn't know how to report this yet; if this patch is
generally
> acceptable, I can try to fix that and update the manpage, etc.
Yes, auditctl -l will have to be updated. If you want to do that, it would
be
helpful. Also, see the comments on the other patch in case it affects this
one.
It will and I'll update this.
This only supports != and = because those were the only two that really
seemed like meaningful tests for these fields; do you think this should
support <, <=, >, >= as well (I'm assuming that bitmasks wouldn't
make
sense at all)
Cheers,
peter
-Steve
--
Peter Moody Google 1.650.253.7306
Security Engineer pgp:0xC3410038