Bug 1353558
Summary: | Starting docker.service produces SELinux error op=security_compute_av perms=siginh | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan Pazdziora <jpazdziora> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 24 | CC: | adimania, admiller, amurdaca, dwalsh, eparis, gansalmon, ichavero, itamar, jcajka, jchaloup, jonathan, jpazdziora, kernel-maint, labbott, lsm5, madhu.chinakonda, marianne, mchehab, miminar, nalin, pmoore, riek, sdsmall, vbatts |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | kernel-4.7.2-201.fc24 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-09-02 20:52:43 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
Jan Pazdziora
2016-07-07 12:53:20 UTC
On Rawhide or F24 I am seeing lots of these issues. type=SELINUX_ERR msg=audit(1467279926.188:1637): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467279927.251:1667): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467284272.194:89): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467284273.218:114): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467284274.977:202): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467322197.426:1000): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467322209.675:1004): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467322310.560:1045): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467322320.960:1051): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467322443.190:1102): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467322447.295:1121): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467381662.616:1411): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467381663.640:1415): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467381668.565:1433): op=security_compute_av reason=bounds scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=siginh type=SELINUX_ERR msg=audit(1467381733.630:1445): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_lxc_net_t:s0:c544,c880 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr type=SELINUX_ERR msg=audit(1467382241.866:1471): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_lxc_net_t:s0:c478,c576 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr type=SELINUX_ERR msg=audit(1467383542.071:1483): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_lxc_net_t:s0:c478,c576 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr type=SELINUX_ERR msg=audit(1467383661.552:1504): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_lxc_net_t:s0:c499,c827 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr type=SELINUX_ERR msg=audit(1467383745.386:1548): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_lxc_net_t:s0:c1,c2 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr type=SELINUX_ERR msg=audit(1467383766.370:1570): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_qemu_net_t:s0:c595,c1023 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr type=SELINUX_ERR msg=audit(1467385202.122:1603): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_lxc_net_t:s0:c132,c826 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr Does not seem to block anything, but how do I get rid of them. Do I need to say docker_t is bounded by init_t? Without looking closely at the policy, any chance you could try one of the kernels below? * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext Here is the kernel I am running. 4.7.0-0.rc4.git1.1.fc25.x86_64 docker run fedora echo hello grep SELINUX_ERR /var/log/audit/audit.log type=SELINUX_ERR msg=audit(1467923289.773:1348): op=security_compute_av reason=bounds scontext=system_u:system_r:svirt_lxc_net_t:s0:c188,c208 tcontext=system_u:system_r:docker_t:s0 tclass=process perms=getattr # grep SELINUX_ERR /var/log/audit/audit.log # docker run -it --rm --name tools1 -v /sys/fs/selinux:/sys/fs/selinux:ro --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=tools -e IMAGE=centos/tools -v /run:/run -v /var/log:/var/log -v /etc/localtime:/etc/localtime -v /:/host centos/tools # exit # grep SELINUX_ERR /var/log/audit/audit.log # docker run fedora echo hello hello # grep SELINUX_ERR /var/log/audit/audit.log # uname -r 4.7.0-0.rc6.git0.1.1.secnext.fc25.x86_64 Seems like it is fixed in this kernel. Thanks for the testing help. The fix is the commit below which was just pushed as part of the patches for Linux 4.8. If this fix is urgent we would need to appeal to the Fedora Kernel guys to backport this patch, the good news is that it is relatively self-contained and not likely to be problematic. commit 7ea59202db8d20806d9ae552acd1875c3a978bcc Author: Stephen Smalley <sds.gov> Date: Mon May 23 10:54:11 2016 -0400 selinux: Only apply bounds checking to source types The current bounds checking of both source and target types requires allowing any domain that has access to the child domain to also have the same permissions to the parent, which is undesirable. Drop the target bounds checking. KaiGai Kohei originally removed all use of target bounds in commit 7d52a155e38d ("selinux: remove dead code in type_attribute_bounds_av()") but this was reverted in commit 2ae3ba39389b ("selinux: libsepol: remove dead code in check_avtab_hierarchy_callback()") because it would have required explicitly allowing the parent any permissions to the child that the child is allowed to itself. This change in contrast retains the logic for the case where both source and target types are bounded, thereby allowing access if the parent of the source is allowed the corresponding permissions to the parent of the target. Further, this change reworks the logic such that we only perform a single computation for each case and there is no ambiguity as to how to resolve a bounds violation. Under the new logic, if the source type and target types are both bounded, then the parent of the source type must be allowed the same permissions to the parent of the target type. If only the source type is bounded, then the parent of the source type must be allowed the same permissions to the target type. Examples of the new logic and comparisons with the old logic: 1. If we have: typebounds A B; then: allow B self:process <permissions>; will satisfy the bounds constraint iff: allow A self:process <permissions>; is also allowed in policy. Under the old logic, the allow rule on B satisfies the bounds constraint if any of the following three are allowed: allow A B:process <permissions>; or allow B A:process <permissions>; or allow A self:process <permissions>; However, either of the first two ultimately require the third to satisfy the bounds constraint under the old logic, and therefore this degenerates to the same result (but is more efficient - we only need to perform one compute_av call). 2. If we have: typebounds A B; typebounds A_exec B_exec; then: allow B B_exec:file <permissions>; will satisfy the bounds constraint iff: allow A A_exec:file <permissions>; is also allowed in policy. This is essentially the same as #1; it is merely included as an example of dealing with object types related to a bounded domain in a manner that satisfies the bounds relationship. Note that this approach is preferable to leaving B_exec unbounded and having: allow A B_exec:file <permissions>; in policy because that would allow B's entrypoints to be used to enter A. Similarly for _tmp or other related types. 3. If we have: typebounds A B; and an unbounded type T, then: allow B T:file <permissions>; will satisfy the bounds constraint iff: allow A T:file <permissions>; is allowed in policy. The old logic would have been identical for this example. 4. If we have: typebounds A B; and an unbounded domain D, then: allow D B:unix_stream_socket <permissions>; is not subject to any bounds constraints under the new logic because D is not bounded. This is desirable so that we can allow a domain to e.g. connectto a child domain without having to allow it to do the same to its parent. The old logic would have required: allow D A:unix_stream_socket <permissions>; to also be allowed in policy. Signed-off-by: Stephen Smalley <sds.gov> [PM: re-wrapped description to appease checkpatch.pl] Signed-off-by: Paul Moore <paul> No I don't see anything being blocked other then a bogus error message in the audit log. So most people will not see this, and can be fixed when this kernel makes its way upstream. Is the 4.8 kernel expected to come to Fedora 24 as well when it's released? Currently this bug blocks us from moving our automation from Fedora 23 to 24 (due to tests marked as failing) and I'd like to plan future steps. Thank you, Jan (In reply to Jan Pazdziora from comment #8) > Is the 4.8 kernel expected to come to Fedora 24 as well when it's released? That is something you will need to ask the Fedora Kernel Team, I only control the upstream bits. I am pretty sure they will update it when 4.8 is released. Yes, F24 will eventually get the 4.8 kernel, That won't happen for at least a couple of months though given 4.8 is only at -rc2. Given the fix is in Linus' tree, I'm okay with bringing it in. I'll bring it in as part of the 4.7 rebase which should happen either end of this week or next week. Thank you! kernel-4.7.2-200.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c654464bce kernel-4.7.2-100.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-91e80601a0 kernel-4.7.2-200.fc24 has been pushed to the Fedora 24 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-c654464bce kernel-4.7.2-100.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-91e80601a0 kernel-4.7.2-201.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2e5ebfed6d kernel-4.7.2-101.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f1adaaadc6 kernel-4.7.2-201.fc24 has been pushed to the Fedora 24 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-2e5ebfed6d kernel-4.7.2-101.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-f1adaaadc6 kernel-4.7.2-201.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. kernel-4.7.2-101.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. |