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

[Peter Moody]

On Mon, Dec 12, 2011 at 6:40 AM, Steve Grubb <sgrubb at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20111212/be3d6b48/attachment.htm>