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 - SELinux issues with libGLdispatch.so.0.0.0 with move to libglvnd
Summary: SELinux issues with libGLdispatch.so.0.0.0 with move to libglvnd
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 25
Hardware: armv7hl
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2017-02-07 13:26 UTC by Peter Robinson
Modified: 2019-04-29 09:15 UTC (History)
13 users (show)

Fixed In Version: selinux-policy-3.13.1-225.10.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-26 01:37:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Peter Robinson 2017-02-07 13:26:49 UTC
With the deployment of libglvnd on F-25 my gdm greeter stopped appearing on my Raspberry Pi. Host booted up just fine. When I do a "setenfore 0; systemctl restart gdm.server" the GDM login comes up as expected.

I tried relabelling the filesytem but still get the same errors. I get the following errors in the journal:


Feb 07 13:03:15 setroubleshoot[609]: SELinux is preventing gdm-wayland-ses from execmod access on the file /usr/lib/libGLdispatch.so.0.0.0. For complete SELinux messages. run sealert -l 34becf14-3824-4a7a-b1a2-60116570d131
Feb 07 13:03:15 python3[609]: 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

Feb 07 13:03:15 gnome-settings-daemon.desktop[12502]: libGL error: MESA-LOADER: device is not located on the PCI bus
Feb 07 13:03:15 setroubleshoot[609]: SELinux is preventing gdm-wayland-ses from execmod access on the file /usr/lib/libGLdispatch.so.0.0.0. For complete SELinux messages. run sealert -l 34becf14-3824-4a7a-b1a2-60116570d131
Feb 07 13:03:16 python3[609]: 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

Comment 1 Peter Robinson 2017-02-07 13:27:59 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

Comment 2 Peter Robinson 2017-02-07 13:34:27 UTC
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

Comment 3 Hans de Goede 2017-02-09 13:04:04 UTC
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.

Comment 4 Rob Clark 2017-02-09 13:17:30 UTC
(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?

Comment 5 Hans de Goede 2017-02-09 13:41:11 UTC
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 ?

Comment 6 Rob Clark 2017-02-09 15:38:39 UTC
(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.

Comment 7 Hans de Goede 2017-02-09 20:27:07 UTC
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) ?

Comment 8 Lukas Vrabec 2017-02-13 08:25:40 UTC
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.

Comment 9 Peter Robinson 2017-02-13 15:12:24 UTC
That looks to work fine

Comment 10 Hans de Goede 2017-02-13 16:43:28 UTC
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

Comment 11 Fedora Update System 2017-02-20 15:30:55 UTC
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

Comment 12 Hans de Goede 2017-02-20 19:20:33 UTC
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

Comment 13 Fedora Update System 2017-02-22 21:07:20 UTC
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

Comment 14 Fedora Update System 2017-02-26 01:37:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.