Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1298192
Summary: | BUG: SELinux conditional policies are ignored for userspace object managers | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrea Bolognani <abologna> |
Component: | kernel | Assignee: | Paul Moore <pmoore> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 23 | CC: | aanm90, alex.williamson, ben.r.xiao, bugzilla.redhat.com, bz, chemobejk, colin, craig48, daniel, dan, deadletterfile, dmitryburstein, dominick.grift, don.allen, dwalsh, dwoody5654, error, frank, gansalmon, hancock, itamar, jen, john.floyd, john.horne, jonathan, j.orti.alcaine, jpazdziora, jwakely, kernel-maint, kevin, linuxat400, lpancescu, lvrabec, madhu.chinakonda, marius.grosso, mchehab, mgrepl, mhjacks, michael, mkosek, mwc-250sav, ondrejj, orders, plautrba, pmoore, ppisar, reklov, rocketraman, saalwaechter, sigut, stephan.duehr, sudhir, tim, tmraz, v.astafiev, vladimir.rusinov, wshi, zingale |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | kernel-4.3.3-303.fc23 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-01-26 18:24:04 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: | |
Embargoed: |
Description
Andrea Bolognani
2016-01-13 12:40:07 UTC
Have you tried relabeling? This looks very much like an SELinux issue, not something kernel specific. I have tried relabeling, to no avail. I have also tried, while running the latest kernel, creating a new user and adding a job to that user's crontab. That didn't work either. I'm not sure what the culprit might be: I have reported this against the kernel because, among the involved components (kernel, libselinux, cronie) it's the only one that's been recently updated, and because booting with an older kernel is an effective workaround. Feel free to reassign it if you're positive recent changes in the kernel are not the cause of this issues. I can't think of any SELinux changes in the kernel's 4.3 release that would affect cron ... I'm CC'ing mgrepl in case he can think of anything; I suspect this may be a labeling and/or policy issue. FWIW, I just looked on my Rawhide system, and the reporters crontab does appear to be labeled correctly. Glad I found this. I was about to give up on SELinux. This morning I realized that crontab jobs were not running for either root or my user (the only two that had crontabs). # uname -a Linux wombat.wombatz.com 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Please let me know if there is any other input you might need. Me too. Spotted two new issues in logwatch, then a search found this bug. Cron jobs for root and my user both don't run. --------------------- Cron Begin ------------------------ **Unmatched Entries** Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/myuser) FAILED (loading cron table) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/root) FAILED (loading cron table) ---------------------- Cron End ------------------------- # ls -Z /var/spool/cron/root unconfined_u:object_r:user_cron_spool_t:s0 /var/spool/cron/root # uname -a Linux foo 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I can confirm that going back to 4.2.8 works around the issue. Yes. While crontab -l gives the crontab content from "before", crontab is not working for any of the users. The messages are as already described, going back to last version before 4.3.3 "solves" the problem. audit2allow/audit2why do not see any problems. IMO, this should be set to the highest priority/severity. Silently breaking cron jobs is a major problem. *** This bug has been marked as a duplicate of bug 1263328 *** *** Bug 1298816 has been marked as a duplicate of this bug. *** Paul, the problem is with tunable policy - booleans. We have (allow unconfined_t user_cron_spool_t( file ( entrypoint))) as a part of tunable rule. If I allow it directly it works. We see it also for another use cases - dbus+sssd. Is it possible it is caused by kernel? It looks there is no issue with policy here. Paul, it also works if I downgraded kernel. *** Bug 1263328 has been marked as a duplicate of this bug. *** *** Bug 1298607 has been marked as a duplicate of this bug. *** Also seeing this in kernel-4.3.3-300.fc23.x86_64. Cron jobs are not functioning. dogpile. :-) yes, seeing this also *** Bug 1299117 has been marked as a duplicate of this bug. *** Seeing this also on kernel 4.3.3-300.fc23.x86_64. Noticed user crons had stopped running. Jan 18 00:24:01 ears.private crond[16071]: (dan) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/dan) Jan 18 00:24:01 ears.private crond[16071]: (dan) FAILED (loading cron table) Jan 18 00:24:13 ears.private crontab[17432]: (dan) REPLACE (dan) Jan 18 00:24:13 ears.private crontab[17432]: (dan) END EDIT (dan) Jan 18 00:25:01 ears.private crond[16071]: (dan) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/dan) Jan 18 00:25:01 ears.private crond[16071]: (dan) FAILED (loading cron table) Guys, could you try to apply the following workaround $ cat mycron.cil (allow unconfined_t user_cron_spool_t( file ( entrypoint))) and run # semodule -i mycron.cil and reload crond. It works for others. *** Bug 1299034 has been marked as a duplicate of this bug. *** *** Bug 1298597 has been marked as a duplicate of this bug. *** (In reply to Miroslav Grepl from comment #19) > Guys, > could you try to apply the following workaround > > $ cat mycron.cil > (allow unconfined_t user_cron_spool_t( file ( entrypoint))) > > and run > > # semodule -i mycron.cil > > and reload crond. It works for others. > Yes, this worked for me. Cron jobs are now running. My apologies for not thinking about this sooner, thanks to mgrepl for pointing out the problem with the conditional policy, that's the clue ... the fix should be the following patch, which was marked for stable but hasn't hit the F23 kernels yet for some reason (at least as of kernel-4.3.3-301.fc23). The commit below should fix the problem: commit f3bef67992e8698897b584616535803887c4a73e Author: Stephen Smalley <sds.gov> Date: Mon Nov 23 16:07:41 2015 -0500 selinux: fix bug in conditional rules handling commit fa1aa143ac4a ("selinux: extended permissions for ioctls") introduced a bug into the handling of conditional rules, skipping the processing entirely when the caller does not provide an extended permissions (xperms) structure. Access checks from userspace using /sys/fs/selinux/access do not include such a structure since that interface does not presently expose extended permission information. As a result, conditional rules were being ignored entirely on userspace access requests, producing denials when access was allowed by conditional rules in the policy. Fix the bug by only skipping computation of extended permissions in this situation, not the entire conditional rules processing. Reported-by: Laurent Bigonville <bigon> Signed-off-by: Stephen Smalley <sds.gov> [PM: fixed long lines in patch description] Cc: stable.org # 4.3 Signed-off-by: Paul Moore <pmoore> You should be able to run any 4.4 based kernel, including current Rawhide or pcmoore/kernel-secnext kernels, and the cron problem should be resolved. Please try one of the newer kernels and let me know if you are still seeing the problem, if so we'll work to get the patch backported to F23. * https://copr.fedoraproject.org/coprs/pcmoore/kernel-secnext I'm running kernel-4.5.0-0.rc0.git1.1.fc24.x86_64 installed from rawhide and the issue with cron is indeed no longer present. The pcmoore/kernel-secnext repository did not work for me, but let me know if I can help with further testing. I confirm kernel-4.3.3-301.fc23 is broken, kernel-4.4.0-1.fc24 with the same F23 user space is fixed for me. The at jobs work again. (In reply to Andrea Bolognani from comment #24) > The pcmoore/kernel-secnext repository did not work for me, but let me know if I > can help with further testing. Slightly unrelated to this BZ, but can you explain what went wrong, did you follow the instructions on the page? The patch has been added in Fedora git. It will be in the next build. (In reply to Paul Moore from comment #26) > (In reply to Andrea Bolognani from comment #24) > > The pcmoore/kernel-secnext repository did not work for me, but let me know if I > > can help with further testing. > > Slightly unrelated to this BZ, but can you explain what went wrong, did you > follow the instructions on the page? Yup, here's what I did: $ sudo dnf copr enable pcmoore/kernel-secnext You are about to enable a Copr repository. Please note that this repository is not part of the main Fedora distribution, and quality may vary. The Fedora Project does not exercise any power over the contents of this repository beyond the rules outlined in the Copr FAQ at <https://fedorahosted.org/copr/wiki/UserDocs#WhatIcanbuildinCopr>, and packages are not held to any quality or security level. Please do not file bug reports about these packages in Fedora Bugzilla. In case of problems, contact the owner of this repository. Do you want to continue? [y/N]: y Repository successfully enabled. $ sudo dnf update Failed to synchronize cache for repo 'pcmoore-kernel-secnext' from 'https://copr-be.cloud.fedoraproject.org/results/pcmoore/kernel-secnext/fedora-23-x86_64/': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried, disabling. I see now that the packages are only built for rawhide, so of course looking for the F23 repository couldn't work :) (In reply to Andrea Bolognani from comment #28) > I see now that the packages are only built for rawhide, so of course > looking for the F23 repository couldn't work :) Yes, that would be the problem :) I was afraid something else was wrong. Thanks for giving it a try and reporting back. (In reply to Andrea Bolognani from comment #24) > I'm running > > kernel-4.5.0-0.rc0.git1.1.fc24.x86_64 > > installed from rawhide and the issue with cron is indeed no longer > present. The pcmoore/kernel-secnext repository did not work for me, > but let me know if I can help with further testing. Compiled 4.5.0-0.rc0.git1.1.fc23.x86_64 today and can confirm that the cron issue is no longer present. # sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 30 Tested all services and they seem to work normally. The cron table is loaded and all cron jobs are executed normally. I can confirm kernel 4.3.3.302.fc23 works on my systems and also resolves a SATA issue that cropped up on them after the update to 4.3.3.300.fc23 as well. kernel-4.3.3-302.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-db9fedd7c4 kernel-4.3.3-303.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b59fd603be kernel-4.3.3-303.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b59fd603be *** Bug 1301007 has been marked as a duplicate of this bug. *** kernel-4.3.3.303.fc23 install on x86_64, cron problem appears to be resolved. *** Bug 1301327 has been marked as a duplicate of this bug. *** kernel-4.3.3-303.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. *** Bug 1306104 has been marked as a duplicate of this bug. *** *** Bug 1300531 has been marked as a duplicate of this bug. *** I am new to SELinux but have been using Fedora since 16. Currently using in permissive mode and SELinux gave errors for /var/spool/cron/username as follows: SELinux: Context system_u:object_r::s0 is not valid (left unmapped). After implementing the fix in comment 19 SELinux does not have errors but I get messages from crond as: NULL security context for user, but SELinux in permissive mode, continuing () Is this as it should be or do I need to do something in addition to the fix in comment 19? Thanks, David (In reply to David from comment #41) > I am new to SELinux but have been using Fedora since 16. > Currently using in permissive mode and SELinux gave errors for > /var/spool/cron/username as follows: > > SELinux: Context system_u:object_r::s0 is not valid (left unmapped). > > After implementing the fix in comment 19 SELinux does not have errors but I > get messages from crond as: > > NULL security context for user, but SELinux in permissive mode, continuing () > > Is this as it should be or do I need to do something in addition to the fix > in comment 19? I would suggest filing a new BZ for your problem as it appears to be unrelated to this issue discussed here. |