Bug 221663

Summary:	LSPP: The auidt record for some ipc system calls add 0x100 to the cmd argument audited.
Product:	Red Hat Enterprise Linux 5	Reporter:	Kylene J Hall <kylene>
Component:	kernel	Assignee:	Jan Glauber <jglauber>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.0	CC:	dzickus, iboverma, linda.knippers
Target Milestone:	---
Target Release:	---
Hardware:	s390x
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-01-10 15:51:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kylene J Hall 2007-01-05 22:24:24 UTC

Description of problem:
The auidt record for some ipc system calls add 0x100 to the last argument
audited.  Specifically calls to semctl and msgctl demonstrate this.
Examples: 

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


Version-Release number of selected component (if applicable):
audit-1.3.1-1.el5

How reproducible:
always

Steps to Reproduce:
1. Setup auditing to audit the ipc system call
2. Perform a semctl or msgctl as described above
3. Look at the audit log.
  
Actual results:
See the a3 argument for semctl or a2 argument for msgctl is actually equal to
the value input + 0x100

Expected results:
See the a3 argument for semctl or a2 argument for msgctl be equal to the value
input (such as IPC_RMID or IPC_STAT)

Additional info:

Comment 2 Eric Paris 2007-01-09 16:46:24 UTC

/*
 * 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.  I believe for all arches we deal with it will happen for everything.
 I think this just needs to be documented in the same place as the last similar
auditing "discrepency"

Comment 3 Jay Turner 2007-01-10 15:10:14 UTC

QE ack for RHEL5 . . . granted, it's after the patch submission deadline as well
as the RC kernel freeze, so not sure what this does to us, but appears this
change is necessary for LSPP.

Comment 4 Eric Paris 2007-01-10 15:51:03 UTC

I'm closing this as 'not a bug'  the |= 0x100 you see in the result is simply
userspace telling the kernel the version it supports.  I would suggest that all
automated audit tests simply &= ~0x100 (or something along those lines) before
checking the result.  This is not a bug and is working as intended.