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?]
Current policy should allow unconfined_t to have these perms. If you
have allow_execmod set?
