vmware: execmod for /lib/tls/libc-2.3.4.so, /lib/libnss_files-2.3.4.so, /lib/ld-2.3.4.so?

[Daniel J Walsh]

Tom London wrote:

>Running targeted, latest Rawhide.
>
>VMware now produces the following:
>
>Feb 15 07:31:38 localhost kernel: audit(1108481498.195:0): avc: 
>denied  { execmod } for  pid=2911 comm=vmnet-bridge
>path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=327780
>scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
>tclass=file
>Feb 15 07:31:38 localhost kernel: audit(1108481498.255:0): avc: 
>denied  { execmod } for  pid=2915 comm=vmware-ping
>path=/lib/tls/libc-2.3.4.so dev=dm-0 ino=327780
>scontext=user_u:system_r:initrc_t tcontext=system_u:object_r:lib_t
>tclass=file
>Feb 15 07:31:38 localhost VMware[init]: /usr/bin/vmware-ping: error
>while loading shared libraries: /lib/tls/libc.so.6: cannot apply
>additional memory protection after relocation: Permission denied
><<<SNIP>>>
>Feb 15 07:47:53 localhost kernel: audit(1108482473.711:0): avc: 
>denied  { execmod } for  pid=6297 comm=vmnet-dhcpd
>path=/lib/libnss_files-2.3.4.so dev=dm-0 ino=556112
>scontext=root:system_r:initrc_t tcontext=system_u:object_r:lib_t
>tclass=file
><<<SNIP>>>
>Feb 15 08:45:20 localhost kernel: audit(1108485920.125:0): avc: 
>denied  { execmod } for  pid=5004 comm=vmnet-bridge
>path=/lib/ld-2.3.4.so dev=dm-0 ino=327776
>scontext=root:system_r:initrc_t tcontext=system_u:object_r:ld_so_t
>tclass=file
>
>Could tag /lib/tls/libc* and /lib/libnss_files* as texrel_shlib_t, but
>what about /lib/ld-*?
>Seperate domain for VMware?
>
>I'm testing this on a targeted system; not sure impact on strict policy.
>
>tom
>
>[Minor point/question: The AVC shows the libraries as lib_t, even
>though they are shlib_t. The symbolic links (e.g., /lib/tls/libc.so.6)
>are lib_t, however.... Should the AVC have tcontext of the link or the
>file?]
>  
>
Targeted policy now equates lib_t and shlib_t so this is probably what 
is happening.
Links should be lib_t.