Created attachment 319441 [details]
SELinux full AVC denial message

nvidia graphics card with the open source driver?

Hi,

Yes. You are right. Nvidia 6200 with the open source driver.

Also a problem on the x86_64 platform: can we change the platform here to all and then mark Bug 467045 as a duplicate?

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.

(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.

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.

(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).

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?

(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?

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)

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?

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.

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

> 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.

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

Closing.