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 1353558 - Starting docker.service produces SELinux error op=security_compute_av perms=siginh
Summary: Starting docker.service produces SELinux error op=security_compute_av perms=s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-07 12:53 UTC by Jan Pazdziora
Modified: 2016-09-02 23:19 UTC (History)
24 users (show)

Fixed In Version: kernel-4.7.2-201.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-02 20:52:43 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Jan Pazdziora 2016-07-07 12:53:20 UTC 
Description of problem:

Starting docker.service with systemctl produces SELinux error 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

Version-Release number of selected component (if applicable):

selinux-policy-3.13.1-191.fc24.3.noarch
docker-1.10.3-21.git19b5791.fc24.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. systemctl start docker

Actual results:

SELinux error

type=SELINUX_ERR msg=audit(1467895329.542:133): 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

Expected results:

No SELinux error.

Additional info:
Comment 2 Daniel Walsh 2016-07-07 18:17:45 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?
Comment 3 Paul Moore 2016-07-07 20:07:19 UTC 
Without looking closely at the policy, any chance you could try one of the kernels below?

* https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext
Comment 4 Daniel Walsh 2016-07-07 20:28:43 UTC 
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
Comment 5 Daniel Walsh 2016-07-07 20:35:30 UTC 
# 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.
Comment 6 Paul Moore 2016-07-07 21:10:30 UTC 
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>
Comment 7 Daniel Walsh 2016-07-07 21:21:35 UTC 
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.
Comment 8 Jan Pazdziora 2016-08-16 08:57:15 UTC 
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
Comment 9 Paul Moore 2016-08-16 12:50:21 UTC 
(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.
Comment 10 Daniel Walsh 2016-08-16 12:59:50 UTC 
I am pretty sure they will update it when 4.8 is released.
Comment 11 Laura Abbott 2016-08-16 14:33:45 UTC 
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.
Comment 12 Jan Pazdziora 2016-08-16 14:37:27 UTC 
Thank you!
Comment 13 Fedora Update System 2016-08-23 16:04:27 UTC 
kernel-4.7.2-200.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c654464bce
Comment 14 Fedora Update System 2016-08-23 20:10:07 UTC 
kernel-4.7.2-100.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-91e80601a0
Comment 15 Fedora Update System 2016-08-24 17:25:09 UTC 
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
Comment 16 Fedora Update System 2016-08-24 17:52:41 UTC 
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
Comment 17 Fedora Update System 2016-08-29 16:20:31 UTC 
kernel-4.7.2-201.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2e5ebfed6d
Comment 18 Fedora Update System 2016-08-29 16:22:45 UTC 
kernel-4.7.2-101.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f1adaaadc6
Comment 19 Fedora Update System 2016-08-31 12:58:24 UTC 
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
Comment 20 Fedora Update System 2016-08-31 12:58:50 UTC 
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
Comment 21 Fedora Update System 2016-09-02 20:51:22 UTC 
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.
Comment 22 Fedora Update System 2016-09-02 23:19:59 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.