| Summary: | systemd may be hard coding SELinux security identifiers | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dominick Grift <dominick.grift> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | dominick.grift, dwalsh, harald, johannbg, lnykryn, lvrabec, mgrepl, msekleta, plautrba, systemd-maint, vpavlin, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-19 10:23:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
and why is this a systemd bug? 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 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? i am seeing this on bootup Harald, I don't see those types hard coded into the systemd source. Are those labels somehow pulled into the initrd? (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. 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 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. |
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