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 1419944
Summary: | SELinux issues with libGLdispatch.so.0.0.0 with move to libglvnd | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Robinson <pbrobinson> |
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 25 | CC: | dominick.grift, dwalsh, hdegoede, kwizart, leigh123linux, lvrabec, mgrepl, plautrba, pmoore, pwhalen, rclark, ssekidde, xgl-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | armv7hl | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | selinux-policy-3.13.1-225.10.fc25 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-02-26 01:37:46 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: | |||
Bug Depends On: | |||
Bug Blocks: | 245418 |
Description
Peter Robinson
2017-02-07 13:26:49 UTC
The output of the sealert is as follows: $ sealert -l 34becf14-3824-4a7a-b1a2-60116570d131 SELinux is preventing gdm-wayland-ses from execmod access on the file /usr/lib/libGLdispatch.so.0.0.0. ***** Plugin allow_execmod (91.4 confidence) suggests ********************* If you want to allow gdm-wayland-ses to have execmod access on the libGLdispatch.so.0.0.0 file Then you need to change the label on '/usr/lib/libGLdispatch.so.0.0.0' Do # semanage fcontext -a -t textrel_shlib_t '/usr/lib/libGLdispatch.so.0.0.0' # restorecon -v '/usr/lib/libGLdispatch.so.0.0.0' ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that gdm-wayland-ses should be allowed execmod access on the libGLdispatch.so.0.0.0 file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'gdm-wayland-ses' --raw | audit2allow -M my-gdmwaylandses # semodule -X 300 -i my-gdmwaylandses.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:lib_t:s0 Target Objects /usr/lib/libGLdispatch.so.0.0.0 [ file ] Source gdm-wayland-ses Source Path gdm-wayland-ses Port <Unknown> Host rpi-workstation.home.roving-it.com Source RPM Packages Target RPM Packages libglvnd-0.2.999-10.gitdc16f8c.fc25.armv7hl Policy RPM selinux-policy-3.13.1-225.6.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name rpi-workstation.home.roving-it.com Platform Linux rpi-workstation.home.roving-it.com 4.9.8-199.pr1.fc25.armv7hl #1 SMP Mon Feb 6 19:10:33 GMT 2017 armv7l armv7l Alert Count 3690 First Seen 2016-07-25 20:50:22 BST Last Seen 2017-02-07 13:03:11 GMT Local ID 34becf14-3824-4a7a-b1a2-60116570d131 Raw Audit Messages type=AVC msg=audit(1486472591.278:6861): avc: denied { execmod } for pid=12502 comm="gnome-settings-" path="/usr/lib/libGLdispatch.so.0.0.0" dev="mmcblk0p4" ino=43414 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file permissive=1 Hash: gdm-wayland-ses,xdm_t,lib_t,file,execmod Various versions for reference. Not sure if this is something that needs resolution in libglvnd or selinux-policy itself. mesa-libgbm-13.0.4-1.fc25.armv7hl mesa-libEGL-13.0.4-1.fc25.armv7hl mesa-libGLU-9.0.0-10.fc24.armv7hl mesa-libGL-13.0.4-1.fc25.armv7hl mesa-libGLES-13.0.4-1.fc25.armv7hl mesa-libxatracker-13.0.4-1.fc25.armv7hl mesa-libglapi-13.0.4-1.fc25.armv7hl mesa-libwayland-egl-13.0.4-1.fc25.armv7hl mesa-filesystem-13.0.4-1.fc25.armv7hl mesa-dri-drivers-13.0.4-1.fc25.armv7hl selinux-policy-3.13.1-225.6.fc25.noarch selinux-policy-targeted-3.13.1-225.6.fc25.noarch libglvnd-gles-0.2.999-10.gitdc16f8c.fc25.armv7hl libglvnd-0.2.999-10.gitdc16f8c.fc25.armv7hl libglvnd-egl-0.2.999-10.gitdc16f8c.fc25.armv7hl libglvnd-glx-0.2.999-10.gitdc16f8c.fc25.armv7hl Hmm, so for the record things work fine on x86. I wonder if this could be due to the dispatching somehow working differently on ARM, or if this is because of selinux policy differences ? Rob Clark, do you have any idea if this could be caused by the way we do glvnd dispatch on ARM ? Re-assigning this to selinux-policy for now, so that the selinux team can take a look at this too, it can be re-assigned back to libglvnd if that is where the fix needs to be done. (In reply to Hans de Goede from comment #3) > Hmm, so for the record things work fine on x86. > > I wonder if this could be due to the dispatching somehow working differently > on ARM, or if this is because of selinux policy differences ? > > Rob Clark, do you have any idea if this could be caused by the way we do > glvnd dispatch on ARM ? > > Re-assigning this to selinux-policy for now, so that the selinux team can > take a look at this too, it can be re-assigned back to libglvnd if that is > where the fix needs to be done. I think it must somehow be an selinux policy difference. I'm not really an expert in selinux, but at a high level (from the PoV of which .so's are involved), there really shouldn't be any difference between how glvnd works on arm vs x86. (I think on x86 we are using tls which isn't implemented yet on arm.. but that is just implementation detail of the generated stubs) well, I guess one potential difference is /usr/lib/libGLdispatch.so.0.0.0 vs /usr/lib64 maybe compare selinux labels on libGLdispatch on armv7 vs x86? Ok, I've done some debugging on this and it seems that the arm version of libGLdispatch somehow ends up containing some text relocations, for more on this see: https://www.akkadia.org/drepper/textrelocs.html Specifically the problem seems to be: [hans@shalem linux]$ eu-findtextrel ~/libGLdispatch.so.0.0.0 either the file containing the function '_glapi_get_current' or the file containing the function '' is not compiled with -fpic/-fPIC Note this is using an x86 eu-findtextrel on the arm binary, not sure how good an idea that is ... Like culprit seems to be: libglvnd/src/GLdispatch/vnd-glapi/entry_armv7_tsd.c . Rob, my ARM asm writing skills are none existing any chance you could take a look at this ? Or maybe we simply need to mark libGLdispatch.so.0 as textrel_shlib_t on ARM ? (In reply to Hans de Goede from comment #5) > [hans@shalem linux]$ eu-findtextrel ~/libGLdispatch.so.0.0.0 > either the file containing the function '_glapi_get_current' or the file > containing the function '' is not compiled with -fpic/-fPIC I don't think this is necessarily about the asm code. What that is doing, is generating code with the generated code that is patched up w/ pointer to _glapi_get_current (and _glapi_Current).. so the generated code (which I don't think eu-findtextrel knows anything about) does something like text relocation. But already in pages that are not shared w/ other processes (and are writeable). Maybe eu-findtextrel (and selinux) get confused about: static uint16_t BYTECODE_TEMPLATE[] Which isn't actually executed.. but on armv7 is not const.. probably we should: + static const uint16_t BYTECODE_TEMPLATE[] - static uint16_t BYTECODE_TEMPLATE[] Haven't tried it but my guess is that is enough to make selinux not be confused. If that doesn't do it, then just change the label. We are after all generating code that gets executed so not really sure how selinux is saving us from anything here. Ok I've started a scratch build with the BYTECODE_TEMPLATE made const: https://koji.fedoraproject.org/koji/taskinfo?taskID=17695416 But unfortunately that does not fix the textrel problem. Lukas can you add libGLdispatch.so.0 to the list of libraries which need text relocations / execmod (but on armv7hl only it seems) ? We don't have any policy difference between architectures. Could you please add following context to testing machine: # semanage fcontext -a -t textrel_shlib_t '/usr/lib/libGLdispatch.so.0.0.0' # restorecon -v '/usr/lib/libGLdispatch.so.0.0.0' And then reproduce the scenario? Thanks, Lukas. That looks to work fine Hi, (In reply to Lukas Vrabec from comment #8) > We don't have any policy difference between architectures. > > Could you please add following context to testing machine: > > # semanage fcontext -a -t textrel_shlib_t '/usr/lib/libGLdispatch.so.0.0.0' > # restorecon -v '/usr/lib/libGLdispatch.so.0.0.0' > > And then reproduce the scenario? I can confirm that this fixes the issue for me too. Regards, Hans selinux-policy-3.13.1-225.9.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-31d4ea5eb1 I'm afraid that selinux-policy-3.13.1-225.9.fc25 does not fix this: [root@localhost ~]# semanage fcontext -l | grep libGLdispatch /usr/lib/libGLdispatch/.*\.so(\.[^/]*)* regular file system_u:object_r:textrel_shlib_t:s0 There seems to be a '/' which should not be there at then end of "libGLdispatch": [root@localhost ~]# restorecon -v '/usr/lib/libGLdispatch.so.0.0.0' [root@localhost ~]# ls -Z '/usr/lib/libGLdispatch.so.0.0.0' system_u:object_r:lib_t:s0 /usr/lib/libGLdispatch.so.0.0.0 selinux-policy-3.13.1-225.10.fc25 has been pushed to the Fedora 25 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-2017-31d4ea5eb1 selinux-policy-3.13.1-225.10.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. |