offsets for 64bit IPC mechanisms

offsets for 64bit IPC mechanisms

[Steve Grubb]

Hello,

BZ 221663 was opened to report a problem with some test results. From the 
bugzilla:

semctl(id, 0, IPC_RMID);
Expected argument: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 0 (IPC_RMID)
Actual arguments seen in the audit log: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 
0x100

msgctl(id, IPC_STAT, &buf)
Expected argument: a0 = MSGCTL, a1 = id, a2 = 2 (IPC_STAT)
Actual arguments seen in the audit log: a0 = MSGCTL, a1 = id, a2 = 0x102

The answer was:

/*
 * Version flags for semctl, msgctl, and shmctl commands
 * These are passed as bitflags or-ed with the actual command
 */
#define IPC_OLD 0       /* Old version (no 32-bit UID support on many
                           architectures) */
#define IPC_64  0x0100  /* New version (support 32-bit UIDs, bigger
                           message sizes, etc. */

Looks like userspace will "or" the value with IPC_64 to indicate the version 
it supports.


So the question is, should ausearch report the actual recorded register value, 
or should it "and" the register with IPC_64 ?

-Steve

Re: offsets for 64bit IPC mechanisms

[Linda Knippers]

Steve Grubb wrote:
> Hello,
> 
> BZ 221663 was opened to report a problem with some test results. From the 
> bugzilla:
> 
> semctl(id, 0, IPC_RMID);
> Expected argument: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 0 (IPC_RMID)
> Actual arguments seen in the audit log: a0 = SEMCTL, a1 = id, a2 = 0, a3 = 
> 0x100
> 
> msgctl(id, IPC_STAT, &buf)
> Expected argument: a0 = MSGCTL, a1 = id, a2 = 2 (IPC_STAT)
> Actual arguments seen in the audit log: a0 = MSGCTL, a1 = id, a2 = 0x102
> 
> The answer was:
> 
> /*
>  * Version flags for semctl, msgctl, and shmctl commands
>  * These are passed as bitflags or-ed with the actual command
>  */
> #define IPC_OLD 0       /* Old version (no 32-bit UID support on many
>                            architectures) */
> #define IPC_64  0x0100  /* New version (support 32-bit UIDs, bigger
>                            message sizes, etc. */
> 
> Looks like userspace will "or" the value with IPC_64 to indicate the version 
> it supports.
> 
> 
> So the question is, should ausearch report the actual recorded register value, 
> or should it "and" the register with IPC_64 ?

Since we're auditing syscalls, I think audit should report what the
syscall sees.

-- ljk

Re: offsets for 64bit IPC mechanisms

[Steve Grubb]

On Wednesday 10 January 2007 11:08, Linda Knippers wrote:
> > So the question is, should ausearch report the actual recorded register
> > value, or should it "and" the register with IPC_64 ?
>
> Since we're auditing syscalls, I think audit should report what the
> syscall sees.

OK, that's fine with me. But I wonder where all this should be documented so 
that we don't get bugzilla's opened by concerned users. Would any particular 
man page be better than others?

-Steve

Re: offsets for 64bit IPC mechanisms

[Linda Knippers]

> OK, that's fine with me. But I wonder where all this should be documented so 
> that we don't get bugzilla's opened by concerned users. Would any particular 
> man page be better than others?

Perhaps the auditctl manpage should be clear (if it isn't already) that
its auditing the kernel arguments so they may be different than what was
passed into a library routine of the same name.  Maybe give an example.

This specific one is documented in the Notes section of the semctl(2)
and msgctl(2) manpages, which I think is the right place for the
details.  If someone wants to audit a specific syscall, they should
make sure they understand how the syscall works.

-- ljk