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

issues with IPC_SET_PERM change



I've been running portions of our audit test suite on the lspp.21 kernel
with the 1.2.1 user space tools and have noticed some problems with the
change from IPC to IPC_SET_PERM records.

What I'm seeing is this:

1. When an IPC_SET is done with semctl() or msgctl(), we only get an
   IPC_SET_PERM record on the success case, not on the failure case.
   For shmctl(), we get them for both cases.  In RHEL4, we got the
   information for both cases.  I think we should get them for both
   success and failure.

2. The IPC record used to include the information that is now in
   IPC_SET_PERM and the original information was never captured.
   Do we think anyone will be confused that the information in the
   IPC record has a different meaning now?  It doesn't seem very
   backward compatible.  If we want to be backward compatible with
   the meaning of the IPC record, then I think IPC_SET_PERM should
   become IPC again and we should create a new record type with the
   information that's actually new.

3. The current IPC record includes a qbytes field but this field is
   never initialized so I think it should be omitted if we keep the new
   meaning of the IPC record, or we should change audit_ipc_obj()
   so that we can pass it in.  I don't think its available from the
   information that audit_ipc_obj() has right now.  If we really want
   to capture everything that an IPC_SET can change, then we should
   pass in the value.

4. The IPC_SET_PERM record includes the obj field, which I don't think
   is changed as part of the IPC_SET call, so it seems redundant since
   the same information is in the IPC record.  If its not redundant
   because the information can change, then its probably wrong in the
   shmctl() case.

5. The IPC_SET_PERM record has field names with spaces in them.
   I think we should replace the spaces with underscores.

I'm working on a patch that addresses 1, 3, 4, and 5.  Anyone have
an opinion on 2?

If you're interested, the details of the audit records are below.

-- ljk

The RHEL4 records are from an ia64 box and the lspp.21 records are from
an x86_64 box.

With RHEL4, these are the audit records you get with
a successful semctl set:

type=SYSCALL msg=audit(1146770318.210:196): arch=c0000032 syscall=1108
success=yes exit=0 a0=0 a1=1 a2=1 a3=60000fffffff75b0 items=0 pid=4175
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="syscalls" exe="/usr/local/eal3_testing/audit-test/syscalls/syscalls"
type=IPC msg=audit(1146770318.210:196):  qbytes=0 iuid=502 igid=0 mode=0

and the failure case:

type=SYSCALL msg=audit(1146770318.900:206): arch=c0000032 syscall=1108
success=no exit=-1 a0=8000 a1=1 a2=1 a3=60000fffffff75c0 items=0
pid=4255 auid=500 uid=0 gid=0 euid=502 suid=0 fsuid=502 egid=0 sgid=0
fsgid=0 comm="syscalls"
exe="/usr/local/eal3_testing/audit-test/syscalls/syscalls"
type=IPC msg=audit(1146770318.900:206):  qbytes=0 iuid=502 igid=0 mode=0

The IPC record includes the new values.

With the .21 kernel, this is what you get when running the same test
in the success case:

type=SYSCALL msg=audit(1146691872.791:94): arch=c000003e syscall=66
success=yes exit=0 a0=10000 a1=1 a2=1 a3=7fff328a7e70 items=0 pid=4327
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts2 comm="syscalls"
exe="/usr/local/eal3_testing/audit-test/syscalls/syscalls"
subj=user_u:system_r:unconfined_t:s0-s0:c0.c255
type=IPC_SET_PERM msg=audit(1146691872.791:94):  new qbytes=0 new
iuid=501 new igid=0 new mode=0
obj=user_u:system_r:unconfined_t:s0-s0:c0.c255
type=IPC msg=audit(1146691872.791:94):  qbytes=5a5a5a5a5a5a5a5a iuid=0
igid=0 mode=1c0 obj=user_u:system_r:unconfined_t:s0-s0:c0.c255

and the failure case:

type=SYSCALL msg=audit(1146691112.828:64): arch=c000003e syscall=66
success=no exit=-1 a0=8000 a1=1 a2=1 a3=7fff96610bd0 items=0 pid=3101
auid=500 uid=0 gid=0 euid=501 suid=0 fsuid=501 egid=0 sgid=0 fsgid=0
tty=pts2 comm="syscalls"
exe="/usr/local/eal3_testing/audit-test/syscalls/syscalls"
subj=user_u:system_r:unconfined_t:s0-s0:c0.c255
type=IPC msg=audit(1146691112.828:64):  qbytes=5a5a5a5a5a5a5a5a iuid=0
igid=0 mode=1c0 obj=user_u:system_r:unconfined_t:s0-s0:c0.c255

The IPC record includes the original values, with qbytes not
initialized.


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