Bug 223919 - LSPP: audit does not log obj label when opening an existing POSIX message queue
LSPP: audit does not log obj label when opening an existing POSIX message queue
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Brian Brock
: OtherQA
: 224080 232705 (view as bug list)
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-01-22 20:58 EST by Amy Griffis
Modified: 2009-06-19 09:20 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2007-0959
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 14:21:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Untested patch against lspp.63 kernel. (492 bytes, patch)
2007-01-23 18:45 EST, Amy Griffis
no flags Details | Diff
LSPP.65 kernel patch for this issue. (3.87 KB, patch)
2007-02-19 12:18 EST, Eric Paris
no flags Details | Diff

  None (edit)
Description Amy Griffis 2007-01-22 20:58:16 EST
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:
Comment 1 Amy Griffis 2007-01-22 21:03:21 EST
Description should say that audit does *not* collect the inode data.
Comment 2 Amy Griffis 2007-01-23 18:45:58 EST
Created attachment 146376 [details]
Untested patch against lspp.63 kernel.
Comment 3 Eric Paris 2007-01-26 16:43:55 EST
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?
Comment 4 Amy Griffis 2007-01-29 15:51:38 EST
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.
Comment 5 Irina Boverman 2007-02-14 15:52:20 EST
per 2/12 discussion, Amy is reworking this patch and will make it available for
review shortly.
Comment 6 Eric Paris 2007-02-19 12:18:28 EST
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
Comment 7 Eric Paris 2007-02-19 12:27:59 EST
*** Bug 224080 has been marked as a duplicate of this bug. ***
Comment 8 Eric Paris 2007-02-19 12:30:46 EST
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
Comment 9 Amy Griffis 2007-03-05 17:00:55 EST
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
Comment 10 Eric Paris 2007-03-06 16:30:07 EST
When this patch is accepted into an upstream tree I will submitt it for a RHEL5
update.
Comment 11 Steve Grubb 2007-03-17 18:51:57 EDT
Eric, why are there 2 patches for this bug in the lspp.68 kernel?
Comment 12 Eric Paris 2007-03-18 17:23:54 EDT
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?
Comment 13 Steve Grubb 2007-03-18 21:56:42 EDT
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.
Comment 14 Amy Griffis 2007-03-19 14:09:17 EDT
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.
Comment 15 Steve Grubb 2007-03-20 10:46:12 EDT
*** Bug 232705 has been marked as a duplicate of this bug. ***
Comment 18 Don Zickus 2007-06-18 11:19:23 EDT
in 2.6.18-28.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 20 John Poelstra 2007-08-27 14:28:07 EDT
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.
Comment 21 John Poelstra 2007-08-30 20:30:16 EDT
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.
Comment 22 Linda Knippers 2007-08-30 21:08:27 EDT
I re-ran our tests on the U1 beta 1 and they passed.
Comment 24 errata-xmlrpc 2007-11-07 14:21:50 EST
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

Note You need to log in before you can comment on or make changes to this bug.