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:
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".
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]#
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 :-)
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 ?
Created attachment 159050 [details] output of 'readelf -Wa /usr/bin/skype'
/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?
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.
[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.
[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.
Yeah, works if you have allow_execstack set. Turn execstack off and see what happens.
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;
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.
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)
# 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?