Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:


Version-Release number of selected component (if applicable):
selinux-policy-mls-3.7.19-63.el6.noarch
selinux-policy-3.7.19-63.el6.noarch
selinux-policy-minimum-3.7.19-63.el6.noarch
selinux-policy-targeted-3.7.19-63.el6.noarch
selinux-policy-doc-3.7.19-63.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. set up a RHEL-6 machine with MLS policy installed in permissive mode
2. go to runlevel 3
3. create an user
4. set up a password for the user
5. log in as the user
$ id -Z
user_u:user_r:user_t:s0
$ dmesg
klogctl: Permission denied
$ echo $?
1

Actual results:
----
time->Fri Jan 14 05:02:37 2011
type=SYSCALL msg=audit(1294999357.430:72): arch=80000015 syscall=103 success=no exit=-13 a0=3 a1=10017071030 a2=4008 a3=fefefefefefefeff items=0 ppid=1686 pid=1718 auid=501 uid=501 gid=502 euid=501 suid=501 fsuid=501 egid=502 sgid=502 fsgid=502 tty=pts0 ses=4 comm="dmesg" exe="/bin/dmesg" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1294999357.430:72): avc:  denied  { syslog_read } for  pid=1718 comm="dmesg" scontext=user_u:user_r:user_t:s0 tcontext=system_u:system_r:kernel_t:s15:c0.c1023 tclass=system
----

Expected results:
no AVC

The second step should look this way:
2. go to runlevel 3 and switch SELinux to enforcing mode

We allow it for staff and admin SELinux users. I believe we don't want to allow it for guest_u and xguest_u users.

But we could consider to allow it for user_u SELinux user.

user_t should not be allowed to look at the dmesg output.

Ok, I agree. But I should dontaudit it.

No, I want to know if my users are trying to read the syslog content.  They should be told not to do this.

Dmesg output could be considered an information leak.

ok, i understand. I just thought 

$ dmesg
klogctl: Permission denied

is enough. But of course we want to know about that.