Description of problem: When mq_open() is called for an existing POSIX message queue, audit does collect the inode data for the message queue, and so also doesn't collect the osid. Because of another bug (see #223918) audit logs a label based on a garbage osid value. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. create a message queue with mq_open() 2. auditctl -a exit,always -S mq_open 3. open the message queue with mq_open() Actual results: type=SYSCALL msg=audit(1169238624.400:77818): arch=c000003e syscall=240 success=yes exit=3 a0=7ffff506ab25 a1=2 a2=0 a3=0 items=1 ppid=3332 pid=26858 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="do_mq_open" exe="/usr/local/eal4_testing/do_mq_open" subj=staff_u:lspp_test_r:lspp_test_generic_t:s15:c0.c1023 key=(null) type=MQ_OPEN msg=audit(1169238624.400:77818): oflag=0x2 mode=00 mq_flags=0x0 mq_maxmsg=0 mq_msgsize=0 mq_curmsgs=0 type=CWD msg=audit(1169238624.400:77818): cwd="/usr/local/eal4_testing" type=PATH msg=audit(1169238624.400:77818): item=0 name="foo" obj=system_u:object_r:shlib_t:s0 Expected results: foo's actual context is: # ls -Z /dev/mqueue/ -rwx------ root root staff_u:object_r:lspp_test_generic_tmpfs_t:SystemHigh foo Audit should log this context instead of system_u:object_r:shlib_t:s0. Additional info:
Description should say that audit does *not* collect the inode data.
Created attachment 146376 [details] Untested patch against lspp.63 kernel.
type=SYSCALL msg=audit(1169846945.312:43): arch=40000003 syscall=277 success=yes exit=3 a0=80489c1 a1=c0 a2=0 a3=bfa85014 items=3 ppid=1985 pid=2925 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="mq" exe="/storage/tmp/mq" subj=root:system_r:unconfined_t:s0-s0:c0.c255 key=(null) type=MQ_OPEN msg=audit(1169846945.312:43): oflag=0xc0 mode=00 mq_flags=0x0 mq_maxmsg=8 mq_msgsize=4 mq_curmsgs=0 type=CWD msg=audit(1169846945.312:43): cwd="/storage/tmp" type=PATH msg=audit(1169846945.312:43): item=0 name="my_queue" type=PATH msg=audit(1169846945.312:43): item=1 name=(null) inode=9946 dev=00:0d mode=0100000 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:tmpfs_t:s0 type=PATH msg=audit(1169846945.312:43): item=2 name=(null) inode=306 dev=00:0d mode=040777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 type=SYSCALL msg=audit(1169846945.316:44): arch=40000003 syscall=277 success=yes exit=4 a0=80489c1 a1=1 a2=0 a3=0 items=2 ppid=1985 pid=2926 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="mq" exe="/storage/tmp/mq" subj=root:system_r:unconfined_t:s0-s0:c0.c255 key=(null) type=MQ_OPEN msg=audit(1169846945.316:44): oflag=0x1 mode=00 mq_flags=0x0 mq_maxmsg=0 mq_msgsize=0 mq_curmsgs=0 type=CWD msg=audit(1169846945.316:44): cwd="/storage/tmp" type=PATH msg=audit(1169846945.316:44): item=0 name="my_queue" type=PATH msg=audit(1169846945.316:44): item=1 name=(null) inode=9946 dev=00:0d mode=0100000 ouid=0 ogid=0 rdev=00:00 obj=root:object_r:tmpfs_t:s0 So here is the audit record with the changes for a process which creates a new mqueue then spawns a thread which opens the existing mqueue. Can anyone identify the "item=2" line under the original syscall where the mqueue was created? Are we also happy with having the name in item=0 and getting the rest of the record in item=1 for the case this bug was supposed to be affecting?
item=2 is the inode info for the parent directory, which we collect on creates. I agree that having an object's name and inode info in separate path records is ugly. I'll see if I can clean that up.
per 2/12 discussion, Amy is reworking this patch and will make it available for review shortly.
Created attachment 148345 [details] LSPP.65 kernel patch for this issue. Needs testing before internal kernel submission. This patch should also resolve 224080. I may dupe that bug to this one shortly
*** Bug 224080 has been marked as a duplicate of this bug. ***
Since 224080 and this bug are using the same patch I closed 224080 as a dup of this bug. However this bug not needs to test not only mq_open but also mq_timedreceive. *************** Audit does not log an obj label for the message queue for the mq_timedreceive and mq_timedsend syscalls. Because MLS checks are performed for these operations, audit must log the obj label in order to meet LSPP cert requirements. Steps to Reproduce: 1. create a message queue with mq_open() 2. auditctl -a exit,always -S mq_timedsend 3. open the message queue with mq_open() 4. send a message via mq_timedsend() Actual results: type=SYSCALL msg=audit(1169592467.169:78417): arch=c000003e syscall=242 success=yes exit=0 a0=3 a1=4008f6 a2=b a3=1 items=0 ppid=3332 pid=29124 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="do_mq_timedsend" exe="/usr/local/eal4_testing/do_mq_timedsend" subj=staff_u:lspp_test_r:lspp_harness_t:s15 key=(null) type=MQ_SENDRECV msg=audit(1169592467.169:78417): mqdes=3 msg_len=11 msg_prio=1 abs_timeout_sec=0 abs_timeout_nsec=0 Expected results: Expect some additional records, e.g.: type=CWD msg=audit(1169592467.169:78417): cwd="/usr/local/eal4_testing" type=PATH msg=audit(1169592467.169:78417): item=1 name=(null) inode=168458 dev=00:0d mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:lspp_test_generic_tmpfs_t:s15:c0.c1023
Verified all 3 of these in lspp.66 kernel. Log for opening existing mqueue: type=SYSCALL msg=audit(1173132255.603:7472): arch=c000003e syscall=240 success=yes exit=3 a0=7fffb508994e a1=0 a2=0 a3=0 items=1 ppid=22633 pid=5438 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="do_mq_open" exe="/usr/local/eal4_testing/audit-test/utils/bin/do_mq_open" subj=staff_u:lspp_test_r:lspp_harness_t:s15:c0.c1023 key=(null) type=MQ_OPEN msg=audit(1173132255.603:7472): oflag=0x0 mode=00 mq_flags=0x0 mq_maxmsg=0 mq_msgsize=0 mq_curmsgs=0 type=CWD msg=audit(1173132255.603:7472): cwd="/usr/local/eal4_testing/audit-test/utils/bin" type=PATH msg=audit(1173132255.603:7472): item=0 name="test_mq" inode=137328 dev=00:0d mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:lspp_harness_tmpfs_t:s15:c0.c1023 Log for mq_timedsend: type=SYSCALL msg=audit(1173132129.177:7464): arch=c000003e syscall=242 success=yes exit=0 a0=3 a1=4008d3 a2=5 a3=0 items=1 ppid=22633 pid=5178 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="do_mq_timedsend" exe="/usr/local/eal4_testing/audit-test/utils/bin/do_mq_timedsend" subj=staff_u:lspp_test_r:lspp_harness_t:s15:c0.c1023 key=(null) type=MQ_SENDRECV msg=audit(1173132129.177:7464): mqdes=3 msg_len=5 msg_prio=0 abs_timeout_sec=0 abs_timeout_nsec=0 type=PATH msg=audit(1173132129.177:7464): item=0 name=(null) inode=137328 dev=00:0d mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:lspp_harness_tmpfs_t:s15:c0.c1023 Log for mq_timedreceive: type=SYSCALL msg=audit(1173132172.279:7468): arch=c000003e syscall=243 success=no exit=-90 a0=3 a1=7fff4731b7f0 a2=100 a3=0 items=1 ppid=22633 pid=5191 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="do_mq_timedrece" exe="/usr/local/eal4_testing/audit-test/utils/bin/do_mq_timedreceive" subj=staff_u:lspp_test_r:lspp_harness_t:s15:c0.c1023 key=(null) type=MQ_SENDRECV msg=audit(1173132172.279:7468): mqdes=3 msg_len=256 msg_prio=0 abs_timeout_sec=0 abs_timeout_nsec=0 type=PATH msg=audit(1173132172.279:7468): item=0 name=(null) inode=137328 dev=00:0d mode=0100700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:lspp_harness_tmpfs_t:s15:c0.c1023
When this patch is accepted into an upstream tree I will submitt it for a RHEL5 update.
Eric, why are there 2 patches for this bug in the lspp.68 kernel?
See comment #3 for the reason for 2 patches. The first patch causes us to actually collect the "item=1" part of the audit record shown in comment #3. The second patch causes us to realize that item=0 and item=1 should not be seperate items. Thus we end up with an audit record like the one found in comment #9 in which there is only a single PATH record which includes all of the information. Although i did just notice that the mq_timedsend and mq_timedreceive do not actually collect the name= part of the PATH record. Do we really care about that?
If these patches address the same bug, I'd combine them into 1 patch. If they do different things, they belong on 2 bug reports. Also, the patches attached here are not 100% the same as what in the lspp kernel. And the second patch of the two is creating slab corruption.
Responding to comment #12. We don't collect the name because the syscall operates on an mqd. This is consistent with what audit does with other syscalls, e.g. fsetxattr(). The theory is that one would also be auditing mq_open() and the name is present there. AFAIK everyone considers this acceptable.
*** Bug 232705 has been marked as a duplicate of this bug. ***
in 2.6.18-28.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot3 on partners.redhat.com. Requested action: Please verify that your issue is fixed as soon as possible to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. More assistance: If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
A fix for this issue should have been included in the packages contained in the RHEL5.1-Snapshot4 on partners.redhat.com. Requested action: Please verify that your issue is fixed *as soon as possible* to ensure that it is included in this update release. After you (Red Hat Partner) have verified that this issue has been addressed, please perform the following: 1) Change the *status* of this bug to VERIFIED. 2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified) If this issue is not fixed, please add a comment describing the most recent symptoms of the problem you are having and change the status of the bug to FAILS_QA. If you cannot access bugzilla, please reply with a message to Issue Tracker and I will change the status for you. If you need assistance accessing ftp://partners.redhat.com, please contact your Partner Manager.
I re-ran our tests on the U1 beta 1 and they passed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0959.html