[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: test patch for auditctl inter-field comparisons on euid/uid, egid/gid

On Mon, Dec 12, 2011 at 6:40 AM, Steve Grubb <sgrubb 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.


> 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

#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)


Peter Moody      Google    1.650.253.7306    
Security Engineer  pgp:0xC3410038

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]