On Mon, Dec 12, 2011 at 6:40 AM, Steve Grubb <[email protected]> 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
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
