libffi prevents p11-kit from being usable with selinux

[David Woodhouse]

On Mon, 2015-09-21 at 12:22 +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I am debugging an issue when using p11-kit with apache which is due to
> libffi. I'll explain the issue below, and have some questions even more
> below.
> 
> Once I start apache in Fedora with mod_gnutls using a PKCS #11 HSM I
> get:
> 
> (p11-kit:11686) p11_kit_module_load: in: libp11clientsofthsm.so
> (p11-kit:11686) load_module_from_file_inlock: module path is relative,
> loading from: /usr/lib64/pkcs11
> (p11-kit:11686) load_module_from_file_inlock: loading module from path:
> /usr/lib64/pkcs11/libp11clientsofthsm.so
> (p11-kit:11686) dlopen_and_get_function_list: opened module:
> /usr/lib64/pkcs11/libp11clientsofthsm.so
> ffi_closure_alloc failed
> p11-kit: shouldn't be reached at init_wrapper_funcs
> p11-kit: shouldn't be reached at p11_virtual_wrap
> p11-kit: '*module != NULL' not true at prepare_module_inlock_reentrant
> (p11-kit:11686) p11_kit_module_load: out: fail
> 
> That issue is not there when SELinux is set to not enforcing. The
> SELinux warning is:
> 
> "SELinux is preventing /usr/sbin/httpd from execute access on the file
> /tmp/ffisox7RN (deleted)."
> 
> That is, libffi's temp file which is used to mmap memory for execution
> is blocked by SELinux's policy. I find the policy of blocking execution
> in tmp quite reasonable, so I think that libffi is to blame here.
> 
> The question is, (1) why does p11-kit need the libffi closure for that
> module? I believe that should have been needed only when using the
> proxy module, is that correct? (btw. having a high level description of
>  p11-kit operation would be really helpful)
> 
> If we cannot avoid the closure, any good ideas on how could libffi get
> memory to execute without using /tmp?

This is related to the other outstanding libffi bug we have with
cleanup after fork, with functions that are still in use (by one
process) being deleted by the other process. It's only in a file (which
is the root of that other bug) because SELinux prevented libffi from
executing from private memory in the first place, IIRC.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20150921/c6a14486/attachment.bin>