Bug 246762 - ldd fails on executables needing 'execstack' /'execmem' with SELinux 'enforcing'
Summary: ldd fails on executables needing 'execstack' /'execmem' with SELinux 'enforcing'
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-04 17:34 UTC by Tom London
Modified: 2008-08-02 23:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-12 14:07:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output of 'readelf -Wa /usr/bin/skype' (1.15 MB, text/plain)
2007-07-12 13:36 UTC, Tom London
no flags Details

Description Tom London 2007-07-04 17:34:46 UTC
Description of problem:
'ldd' (/lib/ld-linux.so.2) appears to fail when run against certain executables,
such as skype, vmware, etc. 

SELinux drops an AVC complaining about execmem, and the command fails.

Here is a typical AVC:
type=AVC msg=audit(1183569172.849:123): avc:  denied  { execmem } for  pid=9090
comm="ld-linux.so.2" scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=process
type=SYSCALL msg=audit(1183569172.849:123): arch=40000003 syscall=192 success=no
exit=-13 a0=8048000 a1=aa8000 a2=7 a3=812 items=0 ppid=9089 pid=9090 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
comm="ld-linux.so.2" exe="/lib/ld-2.6.so" subj=system_u:system_r:unconfined_t:s0
key=(null)

Here is copy of a terminal session generating the above AVC, showing 
   1. The command failing in the default enforcing setup.
   2. The command succeeding when SELinux is put into permissive mode
   3. The command failing again when SELinux is put back into enforcing mode
   4. The command succeeding again when the SELinux boolean 'allow_execstack' is
set to one.

This sequence also fails with vmware. Vmware uses 'ldd' both to configure itself
as well as to preload needed libraries.  These both fail because the 'ldd' fails.

This behavior is unexpected to me. Shouldn't 'ldd' work in such cases?

[root@localhost ~]# getenforce
Enforcing
[root@localhost ~]# ldd /usr/bin/skype
        not a dynamic executable
[root@localhost ~]# setenforce 0
[root@localhost ~]# ldd /usr/bin/skype
        linux-gate.so.1 =>  (0x00110000)
        libasound.so.2 => /lib/libasound.so.2 (0x46f1f000)
        librt.so.1 => /lib/librt.so.1 (0x469c3000)
        libQtDBus.so.4 => /usr/lib/libQtDBus.so.4 (0x4ad1a000)
        libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x4b08a000)
        libQtNetwork.so.4 => /usr/lib/libQtNetwork.so.4 (0x4ac80000)
        libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x4ab00000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x46098000)
        libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x45539000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x45a71000)
        libm.so.6 => /lib/libm.so.6 (0x46051000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x455a3000)
        libc.so.6 => /lib/libc.so.6 (0x45efb000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x46153000)
        libdl.so.2 => /lib/libdl.so.2 (0x4607c000)
        /lib/ld-linux.so.2 (0x45edc000)
        libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x4db1d000)
        libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0x4aaa2000)
        libz.so.1 => /lib/libz.so.1 (0x45924000)
        libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x4b083000)
        libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x4a8d4000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x458b3000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0x46d8b000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x45a49000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0x46d21000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0x46d05000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x46471000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x463c4000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x463cf000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x4646a000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x463dd000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x463d8000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4a9e5000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4aa71000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x462a5000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x46257000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x4625c000)
        libcap.so.1 => /lib/libcap.so.1 (0x46b1d000)
        libexpat.so.0 => /lib/libexpat.so.0 (0x46348000)
[root@localhost ~]# setenforce 1
[root@localhost ~]# ldd /usr/bin/skype
        not a dynamic executable
[root@localhost ~]# setsebool allow_execstack=1
[root@localhost ~]# ldd /usr/bin/skype
        linux-gate.so.1 =>  (0x00110000)
        libasound.so.2 => /lib/libasound.so.2 (0x46f1f000)
        librt.so.1 => /lib/librt.so.1 (0x469c3000)
        libQtDBus.so.4 => /usr/lib/libQtDBus.so.4 (0x4ad1a000)
        libQtGui.so.4 => /usr/lib/libQtGui.so.4 (0x4b08a000)
        libQtNetwork.so.4 => /usr/lib/libQtNetwork.so.4 (0x4ac80000)
        libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x4ab00000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x46098000)
        libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x45539000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x45a71000)
        libm.so.6 => /lib/libm.so.6 (0x46051000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x455a3000)
        libc.so.6 => /lib/libc.so.6 (0x45efb000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x46153000)
        libdl.so.2 => /lib/libdl.so.2 (0x4607c000)
        /lib/ld-linux.so.2 (0x45edc000)
        libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x4db1d000)
        libQtXml.so.4 => /usr/lib/libQtXml.so.4 (0x4aaa2000)
        libz.so.1 => /lib/libz.so.1 (0x45924000)
        libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x4b083000)
        libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x4a8d4000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0x458b3000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0x46d8b000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x45a49000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0x46d21000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0x46d05000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x46471000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x463c4000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x463cf000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x4646a000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x463dd000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x463d8000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4a9e5000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4aa71000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x462a5000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x46257000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x4625c000)
        libcap.so.1 => /lib/libcap.so.1 (0x46b1d000)
        libexpat.so.0 => /lib/libexpat.so.0 (0x46348000)
[root@localhost ~]# 

Running 'ldd' with strace, here is where it fails in enforcing mode:

[pid 30658] open("/usr/bin/skype", O_RDONLY) = 3
[pid 30658] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0`|\6\010"..., 512) = 512
[pid 30658] fstat64(3, {st_mode=S_IFREG|0755, st_size=11379356, ...}) = 0
[pid 30658] mmap2(0x8048000, 11173888, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = -1 EACCES (Permission denied)
[pid 30658] close(3)                    = 0

In permissive mode:
[pid 30665] open("/usr/bin/skype", O_RDONLY) = 3
[pid 30665] read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0`|\6\010"..., 512) = 512
[pid 30665] fstat64(3, {st_mode=S_IFREG|0755, st_size=11379356, ...}) = 0
[pid 30665] mmap2(0x8048000, 11173888, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x8048000
[pid 30665] mmap2(0x8af0000, 24576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xaa8) = 0x8af0000
[pid 30665] mmap2(0x8af6000, 105520, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x8af6000
[pid 30665] mmap2(0x8b11000, 184320, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xaad) = 0x8b11000
[pid 30665] close(3)                    = 0

Version-Release number of selected component (if applicable):
glibc-2.6-3
glibc-common-2.6-3

How reproducible:
Every time

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ken YANG 2007-07-11 08:04:36 UTC
i think the "/usr/bin/skype" is a shell script, not executable file. 

in my system, i can ldd "/usr/lib/vmware/bin/vmware", which is the "real"
executable file. i dont have skype, but for vmware, ldd can run in selinux
enforcing mode without error:

-(yangshao@Nerazzurri:pts/1)------------------------------------------------(/usr/lib/vmware/bin)-(6/6)-
-(:15:55:$)-> getenforce
Enforcing
-(yangshao@Nerazzurri:pts/1)------------------------------------------------(/usr/lib/vmware/bin)-(6/6)-
-(:15:57:$)-> ldd /usr/bin/vmware
        not a dynamic executable
-(yangshao@Nerazzurri:pts/1)------------------------------------------------(/usr/lib/vmware/bin)-(6/6)-
-(:15:58:$)-> file /usr/bin/vmware
/usr/bin/vmware: Bourne shell script text executable
-(yangshao@Nerazzurri:pts/1)------------------------------------------------(/usr/lib/vmware/bin)-(6/6)-
-(:15:58:$)-> ldd /usr/lib/vmware/bin/vmware
        linux-gate.so.1 =>  (0x00958000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x49524000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x4d1f0000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x4d1e8000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00503000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x4d321000)
        ..........

because i have not skype in my system, i am not sure why ldd map 
"/usr/bin/skype" as "write && exec".





Comment 2 Tom London 2007-07-11 13:32:24 UTC
No, sorry: /usr/bin/skype is an executable:

[tbl@localhost ~]$ file /usr/bin/skype
/usr/bin/skype: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
[tbl@localhost ~]$ 

For vmware (a shell script), what is failing is a call to 'ldd' within one of
the scripts (/usr/lib/vmware/lib/wrapper-gtk24.sh).

Anyway, for vmware, try this:

[root@localhost bin]# pwd
/usr/lib/vmware/bin
[root@localhost bin]# ls
vmplayer  vmrun  vmware  vmware-acetool  vmware-tray  vmware-vmx
[root@localhost bin]# ldd vmware
        not a dynamic executable
[root@localhost bin]# setsebool allow_execstack=1
[root@localhost bin]# ldd vmware
        linux-gate.so.1 =>  (0x00110000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4b23a000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x46257000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x4625c000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00763000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x463cf000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x463c4000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x46098000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x46153000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x462a5000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x46471000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x463d8000)
        libexpat.so.0 => /lib/libexpat.so.0 (0x46348000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x4aa71000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4a9e5000)
        libXft.so.2 => /usr/lib/libXft.so.2 (0x4b3ab000)
        libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x4a8d4000)
        libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x4a9df000)
        libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x4a99c000)
        libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x4b083000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x4aaa2000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x4c816000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x4c7e3000)
        libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x4ca4b000)
        libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x4ca55000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x0076f000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x4c7c5000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x0080a000)
        libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x4ae61000)
        libglibmm-2.4.so.1 => /usr/lib/libglibmm-2.4.so.1 (0x4ae79000)
        libglibmm_generate_extra_defs-2.4.so.1 =>
/usr/lib/libglibmm_generate_extra_defs-2.4.so.1 (0x0012b000)
        libatkmm-1.6.so.1 => /usr/lib/libatkmm-1.6.so.1 (0x4aecc000)
        libpangomm-1.4.so.1 => /usr/lib/libpangomm-1.4.so.1 (0x4aff7000)
        libgdkmm-2.4.so.1 => /usr/lib/libgdkmm-2.4.so.1 (0x00d87000)
        libgtkmm-2.4.so.1 => /usr/lib/libgtkmm-2.4.so.1 (0x00322000)
        libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x47318000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0x41c06000)
        libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0x00267000)
        libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 (0x00130000)
        libgnomecanvasmm-2.6.so.1 => not found
        librsvg-2.so.2 => /usr/lib/librsvg-2.so.2 (0x00281000)
        libview.so.2 => not found
        libsexymm.so.2 => not found
        libsexy.so.2 => not found
        libz.so.1 => /lib/libz.so.1 (0x45924000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x4c85b000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0x4af13000)
        libcairomm-1.0.so.1 => /usr/lib/libcairomm-1.0.so.1 (0x4af98000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x4646a000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x45a49000)
        libvmwarebase.so.0 => not found
        libvmwareui.so.0 => not found
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4ae6b000)
        libc.so.6 => /lib/libc.so.6 (0x45efb000)
        /lib/ld-linux.so.2 (0x45edc000)
        libm.so.6 => /lib/libm.so.6 (0x46051000)
        libdl.so.2 => /lib/libdl.so.2 (0x4607c000)
        librt.so.1 => /lib/librt.so.1 (0x469c3000)
        libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0x00cfd000)
        libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00cc5000)
        libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x00c4c000)
        libgsf-1.so.114 => /usr/lib/libgsf-1.so.114 (0x4b487000)
        libcroco-0.6.so.3 => /usr/lib/libcroco-0.6.so.3 (0x4b4c2000)
        libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x00ca6000)
        libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00c0d000)
        libssl.so.6 => /lib/libssl.so.6 (0x456be000)
        libcrypto.so.6 => /lib/libcrypto.so.6 (0x45c4b000)
        libavahi-glib.so.1 => /usr/lib/libavahi-glib.so.1 (0x00d74000)
        libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0x00d79000)
        libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0x00d62000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x46b5f000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x45511000)
        libutil.so.1 => /lib/libutil.so.1 (0x46ed3000)
        libbz2.so.1 => /lib/libbz2.so.1 (0x4693b000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x469ce000)
        libcap.so.1 => /lib/libcap.so.1 (0x46b1d000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x4568e000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x455f9000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x45230000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x455d1000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x4552e000)
        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x46d2c000)
[root@localhost bin]# 




Comment 3 Ken YANG 2007-07-12 01:45:50 UTC
sorry, my guess is wrong :-)

now that, as we test, "ldd vmware" and "vmware(launch vmware)" must 
have the same condition(allow_execstack=1), so i guess this bug is 
due to the mechanism of ldd. 

i.e. because ldd want to determine the dynamic libs this program uses, 
it must perform in the same way as executing this program (most of the 
SO are determined at runtime), so we must allow execstack(or execmem...) 
to make ldd work.

this is my guess, i am not sure about it :-)


Comment 4 Jakub Jelinek 2007-07-12 13:01:45 UTC
Can you run /usr/bin/skype at all (isn't it prevented by SELinux policy the
same way)?
Can you post output of
ls -lZ /usr/bin/skype
readelf -Wa /usr/bin/skype
?

Comment 5 Tom London 2007-07-12 13:36:48 UTC
Created attachment 159050 [details]
output of 'readelf -Wa /usr/bin/skype'

Comment 6 Tom London 2007-07-12 13:38:20 UTC
/usr/bin/skype is labeled as 'bin_t'.

Running skype in permissive mode produces: 

type=AVC msg=audit(1184246404.143:30): avc:  denied  { execmem } for  pid=3880
comm="skype" scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=process
type=SYSCALL msg=audit(1184246404.143:30): arch=40000003 syscall=11 success=yes
exit=0 a0=935c158 a1=935b7a0 a2=9318c08 a3=0 items=2 ppid=3678 pid=3880 auid=500
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1
comm="skype" exe="/usr/bin/skype" subj=system_u:system_r:unconfined_t:s0 key=(null)
type=EXECVE msg=audit(1184246404.143:30): a0="skype" 
type=CWD msg=audit(1184246404.143:30):  cwd="/home/tbl"
type=PATH msg=audit(1184246404.143:30): item=0 name="/usr/bin/skype"
inode=5487225 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:bin_t:s0
type=PATH msg=audit(1184246404.143:30): item=1 name=(null) inode=7210527
dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0

Here is output of 'ls -lZ':
[tbl@localhost ~]$ ls -lZ /usr/bin/skype
-rwxr-xr-x  root root system_u:object_r:bin_t          /usr/bin/skype
[tbl@localhost ~]$ 

I attach output of 'readelf -Wa /usr/bin/skype'.

Changing the label of /usr/bin/skype to 'unconfined_execmem_exec_t' allows skype
to run WITHOUT (!!!) AVC in permissive mode (but not in enforcing mode!!!).

But, even with this label, running 'ldd /usr/bin/skype' or just running 'skype'
fails in enforcing mode, and produces the following AVC either in permissive or
enforcing:

Here is AVC produced by 'ldd /usr/bin/skype' with skype labeled as
'unconfined_execmem_exec_t':

type=AVC msg=audit(1184246790.151:34): avc:  denied  { execmem } for  pid=3937
comm="ld-linux.so.2" scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=process
type=SYSCALL msg=audit(1184246790.151:34): arch=40000003 syscall=192 success=no
exit=-13 a0=8048000 a1=aa8000 a2=7 a3=812 items=0 ppid=3936 pid=3937 auid=500
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts1
comm="ld-linux.so.2" exe="/lib/ld-2.6.so" subj=system_u:system_r:unconfined_t:s0
key=(null)

Here is AVC produced trying to run skype in enforcing mode with skype labeled as
'unconfined_execmem_exec_t':

type=AVC msg=audit(1184246805.651:35): avc:  denied  { execmem } for  pid=3939
comm="skype" scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:system_r:unconfined_t:s0 tclass=process
type=SYSCALL msg=audit(1184246805.651:35): arch=40000003 syscall=11 success=no
exit=-13 a0=935c058 a1=935e088 a2=9318c08 a3=0 items=2 ppid=3678 pid=3939
auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
tty=pts1 comm="skype" subj=system_u:system_r:unconfined_t:s0 key=(null)
type=EXECVE msg=audit(1184246805.651:35): a0="skype" 
type=CWD msg=audit(1184246805.651:35):  cwd="/home/tbl"
type=PATH msg=audit(1184246805.651:35): item=0 name="/usr/bin/skype"
inode=5487225 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
obj=system_u:object_r:unconfined_execmem_exec_t:s0
type=PATH msg=audit(1184246805.651:35): item=1 name=(null) inode=7210527
dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0

Can I provide other useful info?



Comment 7 Jakub Jelinek 2007-07-12 14:07:17 UTC
That skype binary is screwed up terribly, where do you got it from?
RWX .text section requires big amount of stupidity and even with recent linkers
a lot of effort, ld will normally change .text flags back to RX.
In this case there is no hope to get any output from ldd, ldd can't blindly
run an executable with LD_TRACE_LOADED_OBJECTS=1 and assume it will honor it.
And when the policy disallows mapping it, verify will fail.

Comment 8 Tom London 2007-07-12 14:25:59 UTC
[Believe skype is latest 'Fedora' rpm from skype.com: skype-1.4.0.74.rpm.]

To be clear, do I have this right:

If SELinux policy prevents a program (e.g., skype, vmware) from executing for
execmem/execstack/..., then ldd of that executable would/should fail.

I'm not arguing that this is wrong, its just that some scripts will likely fail.
For example, /usr/bin/vmware is a shell script that uses 'ldd' to determine what
configuration libraries need to be preloaded.  This could only work then if a
transition to an 'execmem/execstack' domain occurs before running the script.

Does that sound right?

Thanks.



Comment 9 Ken YANG 2007-07-13 06:04:23 UTC
[quote]
If SELinux policy prevents a program (e.g., skype, vmware) from executing for
execmem/execstack/..., then ldd of that executable would/should fail.
[!quote]

yes, ldd will also fail, ldd is implemented by executing program with 
LD_TRACE_LOADED_OBJECTS environment set, e.g. 

LD_TRACE_LOADED_OBJECTS=1 /usr/bin/skype


you label skype with unconfined_execmem_exec_t, but i find in your 
avc, skype still in unconfined_t domain, not transition to 
unconfined_execmem_t, so you still had the "execmem" avc error. 

in policy, there are type transition: 

domtrans_pattern(unconfined_t,unconfined_execmem_exec_t,unconfined_execmem_t)


additionally, i just down and install skype for test:
skype-1.4.0.74-fc5.i586

-(yangshao@Nerazzurri:pts/2)-------------------------------------------------------------------(~)-(3/113)-
-(:13:55:$)-> sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted
-(yangshao@Nerazzurri:pts/2)-------------------------------------------------------------------(~)-(3/113)-
-(:13:55:$)-> lsz /usr/bin/skype 
-rwxr-xr-x  root root system_u:object_r:bin_t          /usr/bin/skype
-(yangshao@Nerazzurri:pts/2)-------------------------------------------------------------------(~)-(3/113)-
-(:13:56:$)-> file /usr/bin/skype
/usr/bin/skype: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
-(yangshao@Nerazzurri:pts/2)-------------------------------------------------------------------(~)-(3/113)-
-(:13:56:$)-> rpm -q selinux-policy-target
package selinux-policy-target is not installed
-(yangshao@Nerazzurri:pts/2)-------------------------------------------------------------------(~)-(3/113)-
-(:13:56:$)-> rpm -q selinux-policy-targeted
selinux-policy-targeted-3.0.2-5.fc8.noarch
-(yangshao@Nerazzurri:pts/2)-------------------------------------------------------------------(~)-(3/113)-
-(:13:56:$)-> getsebool -a | grep "^allow_exec"
allow_execheap --> off
allow_execmem --> off
allow_execmod --> off
allow_execstack --> on
-(yangshao@Nerazzurri:pts/2)-------------------------------------------------------------------(~)-(3/113)-
-(:13:56:$)-> skype


the skype work well, i have not skype account, in my system, skype login 
windows appeared and allow me input account, just like pidgin.

Comment 10 Tom London 2007-07-13 13:20:08 UTC
Yeah, works if you have allow_execstack set.  Turn execstack off and see what
happens.

Comment 11 John Freed 2007-08-11 09:06:47 UTC
The problem isn't in ldd, of course, it's in skype. Clearly it would be better
if Skype Technologies fixed its program.

I, too, tried the suggested approach to allowing skype to execmem, to no avail.
Checking further on creating policies, I succeeded and was able to "restorecon
/usr/bin/skype"

Here is the policy:

[root@localhost audit]# cat skype.te

module skype 1.0;

require {
        type unconfined_t;
        class process execmem;
}

#============= unconfined_t ==============
allow unconfined_t self:process execmem;


Comment 12 Daniel Walsh 2007-08-11 10:21:29 UTC
If you set the boolean allow_execmem you will get the same behaviour.

setsebool -P allow_execmem=1

But the best  solution would be do add a context to skype of
unconfined_execmem_exec_t

semanage fcontext -a -t unconfined_execmem_exec_t /usr/bin/skype
restorecon -v /usr/bin/skype


Which should give execmem to skype and no other apps.


Comment 13 John Freed 2007-08-11 13:42:02 UTC
Hmmm...first off I'm honored to get a reply to my first post from the Man
Himself. :)

I certainly do NOT want allow_execmem=1, the brute-force approach, so as to help
track down buggy apps like skype. I was not aware that the policy cited above
(skype.te) is the equivalent of that. (Sorry but I find the SELinux policy docs
a bit impenetrable, tho I am currently installing the gui policy editor for Fedora.)

I can say with some degree of assuredness that the semanage solution does NOT
work. I suspect it is the equivalent of the solution used above by Tom London
and suggested by the Troubleshooter: chcon -t unconfined_execmem_exec_t
/usr/bin/skype

A short log is at the bottom of this message.

My GUESS is that I need to create a new "skype_t" type and give it execmem
permission, then give the skype_t context to /usr/bin/skype. Unfortunately I
haven't got the slightest idea how to do that :)

Is it useful to anyone to pursue these things? Or should we just shrug our
shoulders and say "Skype is a commercial product and will never comply with any
standards" and be done with it?

I REALLY don't want to give execmem to all apps.

[root@localhost audit]# ls -ldZ /usr/bin/skype
-rwxr-xr-x  root root system_u:object_r:unconfined_execmem_exec_t /usr/bin/skype
[root@localhost audit]# tail -f /var/log/audit/audit.log &
[root@localhost audit]# strace skype
execve("/usr/bin/skype", ["skype"], [/* 26 vars */] <unfinished ...>
+++ killed by SIGKILL +++

type=AVC msg=audit(1186839452.302:304): avc:  denied  { execmem } for  pid=4750
comm="skype" scontext=user_u:system_r:unconfined_t:s0
tcontext=user_u:system_r:unconfined_t:s0 tclass=process
type=SYSCALL msg=audit(1186839452.302:304): arch=40000003 syscall=11 success=no
exit=-13 a0=a10fd68 a1=a0f2f10 a2=a0f88b8 a3=0 items=0 ppid=3512 pid=4750
auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
comm="skype" subj=user_u:system_r:unconfined_t:s0 key=(null)


Comment 14 Daniel Walsh 2007-08-14 15:12:09 UTC
# runcon -t unconfined_execmem_t -- /bin/bash -c /usr/bin/skype 

Of course you could put this in a shell script.

Will work. and you could setup a shell script to do this.  I opened a long
discussion on this on the selinux.gov mailing list.  Turns out that
skype is doing something very early in startup that is causing the problem, and
we really can't get around it except by doing something like above.  

Have you reported this problem to the skype developers?


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