Bug 1393320

Summary: SELinux boolean deny_execmem crashes CFME installation (container)
Product: Red Hat CloudForms Management Engine Reporter: Akram Ben Aissi <abenaiss>
Component: cfme-containerAssignee: Franco Bladilo <fbladilo>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Einat Pacifici <epacific>
Severity: low Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: low    
Version: 5.6.0CC: abenaiss, bazulay, dajohnso, dwalsh, fbladilo, fweimer, jhardy
Target Milestone: GA   
Target Release: cfme-future   
Hardware: All   
OS: Linux   
Whiteboard: container
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-05 15:25:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: Container Management Target Upstream Version:
Embargoed:

Description Akram Ben Aissi 2016-11-09 10:26:38 UTC
Description of problem:

The CFME installation crashes with ruby stack trace in appliance_console.log

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

5.6.2.2

How reproducible:
always

Steps to Reproduce:
1. Install RHEL7.2 and ensure that your version is later than Oct 20 (post dirty cow)
2. docker run --privileged -di cloud forms/cfme4:5.6.2.2
3. jump into the container
4. cloudforms never starts correctly
5. watch logs

Actual results:
cloudforms never starts correctly

Expected results:

cloudforms never starts correctly
Additional info:

To fix it:
Run the following semanage command on the host

semanage boolean --modify deny_execmem --off 



Stack Trace:
/opt/rh/rh-ruby22/root/usr/share/gems/gems/ffi-1.9.8/lib/ffi/library.rb:263:in `attach': PJռ (RuntimeError)
        from /opt/rh/rh-ruby22/root/usr/share/gems/gems/ffi-1.9.8/lib/ffi/library.rb:263:in `attach_function'
        from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/unix/uname.rb:29:in `<class:Uname>'
        from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/unix/uname.rb:8:in `<module:Sys>'
        from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/unix/uname.rb:6:in `<top (required)>'
        from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/uname.rb:16:in `require_relative'
        from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys/uname.rb:16:in `<top (required)>'
        from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys-uname.rb:1:in `require_relative'
        from /opt/rh/cfme-gemset/gems/sys-uname-1.0.2/lib/sys-uname.rb:1:in `<top (required)>'
        from /opt/rh/rh-ruby22/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:128:in `require'
        from /opt/rh/rh-ruby22/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:128:in `rescue in require'
        from /opt/rh/rh-ruby22/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:39:in `require'
        from -e:1:in `<main>'

Comment 2 Akram Ben Aissi 2016-11-09 10:28:58 UTC
I suspect the ffi ruby library to trigger this. This lib is doing mmap PROT_READ calls which now may be block by deny_execmem


In audit.log, I have:
type=AVC msg=audit(1478684500.072:110316): avc:  denied  { execmem } for  pid=115750 comm="ruby" scontext=system_u:system_r:spc_t:s0 tcontext=system_u:system_r:spc_t:s0 tclass=process

Comment 3 Franco Bladilo 2016-11-11 14:39:26 UTC
Akram,

Yes deny_execmem is something that was enabled on recent erratas, ffi seems to have routines to auto-detect selinux but they are probably not working properly inside containers since selinux would appear disabled.

This issue is not limited to CFME, it will affect any application attempting to use ruby ffi inside containers.

I wonder if this is something we can handle with docker-selinux.

Comment 4 Daniel Walsh 2016-11-12 11:49:24 UTC
I would prefer not to disable this for container types in general. Why not just disable the boolean.

Comment 5 Franco Bladilo 2016-11-15 13:22:15 UTC
Dan,

It might be feasible to document and make users actually disable the boolean before attempting to run on docker hosts but this is problematic for Openshift users, as they have no control over the nodes or cluster in general and will prevent them from running unless the cluster admin grant the settings change cluster-wide or labels specially configured nodes for this type of deployments.

Comment 6 Daniel Walsh 2016-11-16 13:22:01 UTC
If this is actually a bug in selinux-policy update then OpenShift should make sure the boolean is turned off within its Ansible Playbooks.

Comment 7 Barak 2016-11-17 20:29:42 UTC
Akram,

I tested latest version on RHEL 7.2 (upgraded to the latest packages)
used selinux-policy-3.13.1-102.el7_3.4

and 

# getsebool -a | grep deny_execmem

deny_execmem --> off


And succeeded running the latest docker image.
Please specify what version of selinux/docker versions you are using.

Comment 8 Barak 2016-12-05 15:25:09 UTC
Closing this bug as the info was not supplied.
In case it comes up again please reopen.