libffi prevents p11-kit from being usable with selinux

Stef Walter stefw at redhat.com
Mon Sep 21 06:12:53 PDT 2015


On 21.09.2015 12:22, 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.

Interesting.

> 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)

Several functions (such as CloseAllSessions()) in PKCS#11 act globally.
By returning a different closure for those function pointers to each
caller, we can scope those effects. We don't do this only in the proxy
module, but throughout the PKCS#11 API.

The following functions are routinely wrapped in a closure:

C_Initialize
C_Finalize
C_CloseAllSessions
C_CloseSession
C_OpenSession

In addition, if things like remoting or logging are enabled, then all
functions are wrapped ... so their arguments can be remoted or logged
respectively.

To turn off use p11_kit_modules_load() with the
P11_KIT_MODULE_UNMANAGED. But obviously and all guarantees about
sharing, or features like logging and/or remoting modules in that
application go out the window.

> If we cannot avoid the closure, any good ideas on how could libffi get
> memory to execute without using /tmp?

 1. Take a look at src/closures.c in libffi. There are already checks
    for selinux. It seems that the /tmp behavior is a fallback because
    the usual mechanism for allocating this memory has failed.

 2. We could precompile NNNN closures into the executable, and these
    would be consumed as necessary. This is how p11-kit used to perform
    this task. It's really horrible code ... but could be done as a last
    resort ... and the code is in the git history.

Cheers,

Stef


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/p11-glue/attachments/20150921/cc8961e7/attachment.sig>


More information about the p11-glue mailing list