vmware: execmod for /lib/tls/libc-2.3.4.so, /lib/libnss_files-2.3.4.so, /lib/ld-2.3.4.so?
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?]
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?
On Tue, 2005-02-15 at 12:10, Daniel J Walsh wrote:
Current policy should allow unconfined_t to have these perms. If you have allow_execmod set?
The audit messages in his posting showed the denials happening for initrc_t, not unconfined_t. Why is vmware running in initrc_t?
On Tue, 15 Feb 2005 13:26:24 -0500, Stephen Smalley sds@epoch.ncsc.mil wrote:
On Tue, 2005-02-15 at 12:10, Daniel J Walsh wrote:
Current policy should allow unconfined_t to have these perms. If you have allow_execmod set?
The audit messages in his posting showed the denials happening for initrc_t, not unconfined_t. Why is vmware running in initrc_t?
-- Stephen Smalley sds@epoch.ncsc.mil National Security Agency
Ah... good point.
VMware has stuff in /etc/init.d to install its kernel modules and setup its networking stuff. So this script is running as initrc_t as is failing. Because of this, I don't even get to run the 'vmware' command.
Sorry for the confusion. tom
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.
On Tue, 15 Feb 2005 12:14:07 -0500, Daniel J Walsh dwalsh@redhat.com wrote:
Current policy should allow unconfined_t to have these perms. If you have allow_execmod set?
allow_execmod --> active
If I 'chcon -t texrel_shlib_t /lib/tls/.... /lib/libnss...' those two AVC go away. But what to do about /lib/ld-*?
BTW, this happened with today's policy: selinux-policy-targeted-1.21.12-3. Previous ones worked just fine.
tom
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Stephen Smalley -
Tom London