This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 465583 - SELinux prevents gnome-screensaver change writable memory segment
SELinux prevents gnome-screensaver change writable memory segment
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-03 22:29 EDT by Deependra Singh Shekhawat
Modified: 2015-01-14 18:21 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-29 00:05:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
SELinux full AVC denial message (3.27 KB, text/plain)
2008-10-03 22:31 EDT, Deependra Singh Shekhawat
no flags Details

  None (edit)
Description Deependra Singh Shekhawat 2008-10-03 22:29:36 EDT
Description of problem:
SELinux shows a AVC when one user who had locked his session in gnome comes back and un-lock the session by giving correct password.

Version-Release number of selected component (if applicable):
libselinux-utils-2.0.73-1.fc10.i386
libselinux-python-2.0.73-1.fc10.i386
selinux-policy-3.5.9-4.fc10.noarch
libselinux-2.0.73-1.fc10.i386
selinux-policy-targeted-3.5.9-4.fc10.noarch
gnome-screensaver-2.24.0-1.fc10.i386


How reproducible:
1. Login to a rawhide box's gnome session. 
2. Then lock screen. 
3. Just after locking the screen try to unlock it with giving the right user    password. 
4. setroubleshootd pops up a avc denial

Actual results:
AVC denial shows up when a user unlocks his/her session. Which is not desirable thing.

Expected results:
A user should session should get unlocked on giving right password. And no SELinux AVC should come up.

Additional info:
Attached with this is the full AVC denial message.

Thanks
Comment 1 Deependra Singh Shekhawat 2008-10-03 22:31:38 EDT
Created attachment 319441 [details]
SELinux full AVC denial message
Comment 2 Ray Strode [halfline] 2008-10-05 18:48:59 EDT
nvidia graphics card with the open source driver?
Comment 3 Deependra Singh Shekhawat 2008-10-05 20:35:40 EDT
Hi,

Yes. You are right. Nvidia 6200 with the open source driver.
Comment 4 Allan Engelhardt 2008-10-16 03:44:00 EDT
Also a problem on the x86_64 platform: can we change the platform here to all and then mark Bug 467045 as a duplicate?
Comment 5 Daniel Walsh 2008-10-23 14:16:26 EDT
This is not an SELinux bug, in that execmem should not be required on a standard system.

You can allow this by setting

# setsebool -P allow_execmem 1

Which will turn off the checking.
Comment 6 Ulrich Drepper 2008-10-23 14:58:13 EDT
(In reply to comment #5)
> This is not an SELinux bug, in that execmem should not be required on a
> standard system.
> 
> You can allow this by setting
> 
> # setsebool -P allow_execmem 1
> 
> Which will turn off the checking.

Come on Dan, don't even propose this.  It's an application bug and it has to be tracked down.  We know from the error report it's an mmap() call which requests writable and executable memory (PROT_WRITE|PROT_EXEC set).  Somebody should grep through the sources or use strace on the program.
Comment 7 Matt Domsch 2008-10-25 10:07:11 EDT
http://domsch.com/linux/fedora/prot_exec.txt
contains a grep of the WHOLE rawhide tree for PROT_EXEC.  Only 1200 occurrances to sift through.  None in the specific packages, so it's going to be in an underlying library.
Comment 8 Ulrich Drepper 2008-10-25 10:32:16 EDT
(In reply to comment #7)
> http://domsch.com/linux/fedora/prot_exec.txt
> contains a grep of the WHOLE rawhide tree for PROT_EXEC.  Only 1200 occurrances
> to sift through.

You can use this code to track down the caller:



#include <dlfcn.h>
#include <execinfo.h>
#include <unistd.h>
#include <sys/mman.h>

#define w(str) \
  write (STDERR_FILENO, str, sizeof (str) - 1)


void *
mmap (void *start, size_t length, int prot, int flags,
      int fd, off_t offset)
{
  static void *(*fp) (void *, size_t, int, int, int, off_t);
  if (fp == NULL)
    fp = dlsym (RTLD_NEXT, "mmap");
  if ((prot & (PROT_WRITE | PROT_EXEC)) == (PROT_WRITE | PROT_EXEC))
    {
      w ("mmap with PROT_WRITE and PROT_EXEC\n");
      void *arr[30];
      int n = backtrace (arr, sizeof (arr) / sizeof (arr[0]));
      backtrace_symbols_fd (arr, n, STDERR_FILENO);
    }
  return fp (start, length, prot,flags, fd, offset);
}


void *
mmap64 (void *start, size_t length, int prot, int flags,
        int fd, off_t offset)
{
  static void *(*fp) (void *, size_t, int, int, int, off_t);
  if (fp == NULL)
    fp = dlsym (RTLD_NEXT, "mmap64");
  if ((prot & (PROT_WRITE | PROT_EXEC)) == (PROT_WRITE | PROT_EXEC))
    {
      w ("mmap64 with PROT_WRITE and PROT_EXEC\n");
      void *arr[30];
      int n = backtrace (arr, sizeof (arr) / sizeof (arr[0]));
      backtrace_symbols_fd (arr, n, STDERR_FILENO);
    }
  return fp (start, length, prot,flags, fd, offset);
}


int
mprotect (void *addr, size_t len, int prot)
{
  static int (*fp) (void *, size_t, int);
  if (fp == NULL)
    fp = dlsym (RTLD_NEXT, "mprotect");
  if ((prot & (PROT_WRITE | PROT_EXEC)) == (PROT_WRITE | PROT_EXEC))
    {
      w ("mprotect with PROT_WRITE and PROT_EXEC\n");
      void *arr[30];
      int n = backtrace (arr, sizeof (arr) / sizeof (arr[0]));
      backtrace_symbols_fd (arr, n, STDERR_FILENO);
    }
  return fp (addr, len, prot);
}



If the debug info is installed addr2line can then be used to determine the source line (see /ust/bin/catchsegv for how this can work).
Comment 9 Matt Domsch 2008-10-27 11:14:24 EDT
airlied: spot surmises this is the mesa code, in particular, in vsnprintf.c, which seems oddly to try to set PROT_EXEC in mcleanup() before freeing the allocated pages.  (this is repeated in 2 other packages with local copies of mesa source).

In addition, mesa execmem.c init_heap() intentionally allocates a heap with PROT_EXEC.

Ideas?
Comment 10 Tom "spot" Callaway 2008-10-27 17:12:44 EDT
(In reply to comment #0)
> Description of problem:
> SELinux shows a AVC when one user who had locked his session in gnome comes
> back and un-lock the session by giving correct password.

Can you retest with mesa-7.2.0-12 or later installed, and see if you can reproduce this?
Comment 11 Matt Domsch 2008-10-27 21:23:25 EDT
I have a system running fully up-to-date rawhide and fully relabeled this morning, with 
$ rpm -qa | grep mesa
mesa-libGLU-7.2-0.13.fc10.x86_64
mesa-libGLU-devel-7.2-0.13.fc10.x86_64
mesa-libGL-devel-7.2-0.13.fc10.x86_64
mesa-libGL-7.2-0.13.fc10.x86_64
mesa-dri-drivers-7.2-0.13.fc10.x86_64
mesa-libGLU-7.2-0.13.fc10.i386
mesa-libGL-7.2-0.13.fc10.i386

$ rpm -q gnome-screensaver
gnome-screensaver-2.24.0-2.fc10.x86_64

and still hit these AVCs.


Summary:

SELinux is preventing gnome-screensav from changing a writable memory segment
executable.

Detailed Description:

The gnome-screensav application attempted to change the access protection of
memory (e.g., allocated using malloc). This is a potential security problem.
Applications should not be doing this. Applications are sometimes coded
incorrectly and request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. If gnome-screensav does not work and you need it to
work, you can configure SELinux temporarily to allow this access until the
application is fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

Allowing Access:

If you trust gnome-screensav to run correctly, you can change the context of the
executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t
'/usr/libexec/gnome-screensaver-gl-helper'". You must also change the default
file context files on the system in order to preserve them even on a full
relabel. "semanage fcontext -a -t unconfined_execmem_exec_t
'/usr/libexec/gnome-screensaver-gl-helper'"

Fix Command:

chcon -t unconfined_execmem_exec_t '/usr/libexec/gnome-screensaver-gl-helper'

Additional Information:

Source Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Context                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Target Objects                None [ process ]
Source                        gnome-screensav
Source Path                   /usr/libexec/gnome-screensaver-gl-helper
Port                          <Unknown>
Host                          mdomsch-ssd.localdomain
Source RPM Packages           gnome-screensaver-2.24.0-2.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-8.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_execmem
Host Name                     mdomsch-ssd.localdomain
Platform                      Linux mdomsch-ssd.localdomain
                              2.6.27.4-47.rc3.fc10.x86_64 #1 SMP Fri Oct 24
                              23:47:24 EDT 2008 x86_64 x86_64
Alert Count                   86
First Seen                    Mon 22 Sep 2008 10:15:57 PM CDT
Last Seen                     Mon 27 Oct 2008 08:06:18 PM CDT
Local ID                      8ce058f9-488c-47b3-81c0-10840ca4a533
Line Numbers                  

Raw Audit Messages            

node=mdomsch-ssd.localdomain type=AVC msg=audit(1225155978.436:18): avc:  denied  { execmem } for  pid=3091 comm="gnome-screensav" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process

node=mdomsch-ssd.localdomain type=SYSCALL msg=audit(1225155978.436:18): arch=c000003e syscall=9 success=yes exit=0 a0=3dbd797000 a1=34000 a2=7 a3=812 items=0 ppid=2645 pid=3091 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gnome-screensav" exe="/usr/libexec/gnome-screensaver-gl-helper" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Comment 12 Matt Domsch 2008-10-27 22:39:16 EDT
in my case, it turns out to be nvidia proprietary libGL.so libraries. :-(

Nuking those, AVCs go away.  Now if only the nv driver would get decent power management such that the laptop doesn't almost melt, that would help.

case solved for me.  Reporter, do you have nVidia proprietary drivers and/or libGL?
Comment 13 Deependra Singh Shekhawat 2008-10-27 23:11:06 EDT
Hi,

Well the system which originally had this problem use to have nvidia 6200 with the open source drive which comes default with the installation that is probably the 'nv'.

Now I don't have that setup anymore but I have installed F10 snap2 and currently updating that setup to current rawhide. This system has intel graphics and I will test whether the issue still remains in this or not and report here soon.

Sorry I can't reproduce the issue with the 'nv' driver because of lack of hardware. 

Thanks.
Comment 14 Deependra Singh Shekhawat 2008-10-27 23:44:15 EDT
Hi,

Just finished updating the rawhide box. I now have the mesa-7.2.0-12 and gnome-screensaver-2.24.0-2.

And I am not able to reproduce the issue I reported. Note that this box has Intel graphics (82865) and I am using 'vesa' as 'intel' driver didn't started X for me.

And yes. By tomorrow I will be getting back the system which had the nvidia card so I will try to reproduce the issue with that hardware too.

And will report the results here.


Thanks
Comment 15 Matthias Clasen 2008-10-28 11:29:59 EDT
> in my case, it turns out to be nvidia proprietary libGL.so libraries. 

If it is caused by proprietary drivers, it is not a blocker.
Comment 16 Deependra Singh Shekhawat 2008-10-28 22:54:29 EDT
Hi,

I got the opportunity to test today's rawhide on the same machine having nvidia. I used the free driver provided by default in fedora. That is the 'nv'.

And I can't reproduce the bug. It works as it was suppose to work.


Thanks
Comment 17 Matt Domsch 2008-10-29 00:05:22 EDT
Closing.

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