Bug 743222
| Summary: | Cannot run screen in MLS mode | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Miroslav Vadkerti <mvadkert> |
| Component: | initscripts | Assignee: | initscripts Maintenance Team <initscripts-maint-list> |
| Status: | CLOSED ERRATA | QA Contact: | Miroslav Vadkerti <mvadkert> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.2 | CC: | azelinka, dwalsh, notting, plautrba |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | Regression | ||
| Fixed In Version: | initscripts-9.03.27-1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Cause
restorecon utility changed its behaviour so it doesn't change MLS level
unless -F parameter is used.
Consequence
/dev and /dev/pts filesystems were not correctly labelled after boot in
systems with configured MLS policy
Fix
restorecon -F is now used for /dev and /dev/pts
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-06 18:10:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 584498, 739953, 747120, 846801, 846802 | ||
Mirek, how is labeled /dev? Looks like this is a bug in initscripts because of the restorecon -F fix in policycoreutils: mount -n /dev/pts >/dev/null 2>&1 [ -n "$SELINUX_STATE" ] && restorecon /dev/pts >/dev/null 2>&1 should be mount -n /dev/pts >/dev/null 2>&1 [ -n "$SELINUX_STATE" ] && restorecon -F /dev/pts >/dev/null 2>&1 well, not only for "restorecon -F /dev/pts" since I see /dev mislabled after booting. I needed also change - /sbin/restorecon -R /dev 2>/dev/null + /sbin/restorecon -R -F /dev 2>/dev/null What is getting mislabeled? -F should not be required to fix the types and the levels should all be s0? Ok this looks like it was caused by a change in restorecon's behaviour to not change the label of a directory if the only thing different is the Level. In this case the system seems to be creating directories at SystemHigh on boot and then needs to fix the directories labels, we should use the -F in this case to force the change to the default. (In reply to comment #7) > Ok this looks like it was caused by a change in restorecon's behaviour to not > change the label of a directory if the only thing different is the Level. In > this case the system seems to be creating directories at SystemHigh on boot and > then needs to fix the directories labels, we should use the -F in this case to > force the change to the default. The problem is, that all the scripts expecting the "old default" behaviour will be broken with the new restorecon. Could we keep the "old default" behaviour and for example add a new option to satisfy the new requirements which led us to the change in restorecon? Yes, I'd be concerned that we will break more than just initscripts. (Modulo the number of people that actually use MLS mode, of course.) Well the fix was added for MLS mode, since there is not very often when the we see an MLS/MCS label outside of s0. The fix will also prevent people from accidently changing the labels on sandboxes or svirt processes. Dan - how many potential situations are there like this where restorecon invocation would need to be changed?
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause
restorecon utility changed its behaviour so it doesn't change MLS level
unless -F parameter is used.
Consequence
/dev and /dev/pts filesystems were not correctly labelled after boot in
systems with configured MLS policy
Fix
restorecon -F is now used for /dev and /dev/pts
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1528.html |
Description of problem: When trying to login via screen as staff_u in MLS I get a AVC denial when screen is trying to access PTY type=SYSCALL msg=audit(1317717208.934:77): arch=c000003e syscall=59 success=yes exit=0 a0=1503480 a1=1503430 a2=150b8b0 a3=7fffe1123280 items=0 ppid=1685 pid=1711 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=tty2 ses=3 comm="screen" exe="/usr/bin/screen" subj=staff_u:staff_r:staff_screen_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1317717208.981:78): avc: denied { search } for pid=1738 comm="screen" name="/" dev=devpts ino=1 scontext=staff_u:staff_r:staff_screen_t:s0-s15:c0.c1023 tcontext=system_u:object_r:devpts_t:s15:c0.c1023 tclass=dir Version-Release number of selected component (if applicable): selinux-policy-3.7.19-113.el6 How reproducible: 100% Steps to Reproduce: 1. login as staff_u user 2. run screen Actual results: screen fails saying no PTY found Expected results: screen works OK