Bug 1008601 - systemd may be hard coding SELinux security identifiers
systemd may be hard coding SELinux security identifiers
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-16 12:29 EDT by Dominick Grift
Modified: 2016-07-19 06:23 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 06:23:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dominick Grift 2013-09-16 12:29:52 EDT
Description of problem:

Using custom security policy: soon after policy is loaded the below security contexts are left unmapped. This suggests that something is hard coding the identifiers.

> # dmesg | grep -i selinux | grep -i unmapped
> [    1.453709] SELinux:  Context system_u:object_r:var_run_t:s0 is not valid (left unmapped).
> [    1.453713] SELinux:  Context system_u:object_r:sysfs_t:s0 is not valid (left unmapped).
> [    1.453717] SELinux:  Context system_u:object_r:root_t:s0 is not valid (left unmapped).
> [    1.453721] SELinux:  Context system_u:object_r:device_t:s0 is not valid (left unmapped).
> [    1.555305] SELinux:  Context system_u:object_r:tmp_t:s0 is not valid (left unmapped).
> [    1.918870] SELinux:  Context system_u:object_r:boot_t:s0 is not valid (left unmapped).

Version-Release number of selected component (if applicable):
systemd-204-9.fc19.x86_64

How reproducible:
load a custom policy with custom identifiers
Comment 1 Harald Hoyer 2013-09-16 12:33:27 EDT
and why is this a systemd bug?
Comment 2 Dominick Grift 2013-09-16 12:47:20 EDT
Sorry, I guess i picked the wrong component but due to the nature of systemd the chances that systemd was somehow involved seemed pretty high to me.

please reassign if needed.

Sorry for the inconvenience.caused by this
Comment 3 Daniel Walsh 2013-09-16 15:20:05 EDT
Dominick could this be just that after you switch out your policy you need to reboot the system, since systemd/udev have done matchpathcon calls that are now invalid?  Or are you seeing this on boot up?
Comment 4 Dominick Grift 2013-09-16 15:25:23 EDT
i am seeing this on bootup
Comment 5 Daniel Walsh 2013-09-16 15:27:47 EDT
Harald, I don't see those types hard coded into the systemd source.  Are those labels somehow pulled into the initrd?
Comment 6 Harald Hoyer 2013-09-16 15:58:27 EDT
(In reply to Daniel Walsh from comment #5)
> Harald, I don't see those types hard coded into the systemd source.  Are
> those labels somehow pulled into the initrd?

Unless cpio records and restores the selinux labels, I see no source for those labels in the initramfs.
Comment 7 Jaroslav Reznik 2015-03-03 10:04:01 EST
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Comment 8 Fedora End Of Life 2016-07-19 06:23:02 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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