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:
I'm running RHEL6.1 snap 3 with the MLS policy in the evaluated
configuration. After I boot the system and log onto the serial
console and run 'restorecon -r -v /', I always get these label changes:
restorecon reset /dev/hpilo context system_u:object_r:device_t:s15:c0.c1023->system_u:object_r:device_t:s0
restorecon reset /dev/ttyS1 context root:object_r:user_tty_device_t:s0->system_u:object_r:tty_device_t:s0
restorecon reset /var/cache/libvirt/qemu context system_u:object_r:virt_cache_t:s0->system_u:object_r:virt_cache_t:s0-s15:c0.c1023
If I log off and log back in on the console as a regular user,
restorecon shows this:
restorecon reset /dev/ttyS1 context staff_u:object_r:user_tty_device_t:s0->system_u:object_r:tty_device_t:s0
Logged off and back in as root:
restorecon reset /dev/ttyS1 context root:object_r:user_tty_device_t:s0->system_u:object_r:tty_device_t:s0
I don't know what the right labels should be but the files seem to be
created in a way that is inconsistent with the policy.
Version-Release number of selected component (if applicable):
selinux-policy-3.7.19-82.el6.noarch
selinux-policy-mls-3.7.19-82.el6.noarch
selinux-policy-targeted-3.7.19-82.el6.noarch
How reproducible:
Very. The hpilo and qemu contexts get changed on every boot.
The /dev/ttyS1 (my console) gets changed after every login.
Steps to Reproduce:
1.boot the system
2.run 'restorecon -r -v /'
3.
Actual results:
The label changes listed above
Expected results:
No label changes
Additional info:
TTy's are labeled differently depending on the user that is logged in. A tty that is not being used by a user would be labeled as tty_device_t, while a tty assigned to a logged in user would be user_tty_device_t, so these labels are correct.
/dev/hplilo being mislabeled is a bug in policy, this directory must be being created by cups? and I guess it has to by SystemHigh?
What does this show?
ls -lZd /var/cache/libvirt
We probably want the context to be.
/var/cache/libvirt -d gen_context(system_u:object_r:virt_cache_t,s0-mls_systemhigh)
/var/cache/libvirt/.* <<None>>
(In reply to comment #2)
> TTy's are labeled differently depending on the user that is logged in. A tty
> that is not being used by a user would be labeled as tty_device_t, while a tty
> assigned to a logged in user would be user_tty_device_t, so these labels are
> correct.
Ok, cool.
> /dev/hplilo being mislabeled is a bug in policy, this directory must be being
> created by cups? and I guess it has to by SystemHigh?
/dev/hpilo is for communicating to the hp management processor (iLO).
I'm not sure what level it should be.
> What does this show?
>
> ls -lZd /var/cache/libvirt
# ls -lZd /var/cache/libvirt
drwx------. root root system_u:object_r:virt_cache_t:SystemLow-SystemHigh /var/cache/libvirt
> We probably want the context to be.
>
>
> /var/cache/libvirt -d
> gen_context(system_u:object_r:virt_cache_t,s0-mls_systemhigh)
> /var/cache/libvirt/.* <<None>>
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 therefore 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-2011-0526.html