Description of problem: P11-kit cannot be used by applications such as apache which are under a strict SELinux policy which prevents executable+writable memory. That is, because it relies on libffi, which uses a temp file to mmap memory for execution, and that's blocked by SELinux's policy. I find the policy of blocking execution in tmp quite reasonable, so I think that libffi and p11-kit are to blame here. 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)." Possible solutions were discussed in the upstream thread at: http://lists.freedesktop.org/archives/p11-glue/2015-September/000576.html
> P11-kit cannot be used by applications such as apache which are under a strict SELinux policy which prevents executable+writable memory. Such applications can currently use the P11_KIT_UNMANAGED module loading option. This disables many of the features of p11-kit ... but that's to be expected, since those features are enabled by the closure support in libffi.
The problem is that the applications don't even know they are using p11-kit. The way we go with transparent PKCS #11 support (in gnutls or engine_pkcs11) means that applications can't switch to unmanaged. For engine_pkcs11 it is even worse because it relies on the proxy module which requires libffi.
Could the proxying be done out-of-process? Split the proxy module and call the real modules in a different process which would also solve the isolated keys problem.
(In reply to Tomas Mraz from comment #3) > Could the proxying be done out-of-process? Split the proxy module and call > the real modules in a different process which would also solve the isolated > keys problem. Yes that could be a possible solution.
One of the reasons we use libffi clusures is remoting PKCS#11. Hence I don't think that would be an easy solution. We should probably just break down and manually build in a fixed set of compiled closures into the p11-kit library that we can use generating closures dymanically with libffi fails.
Another solution which is relevant for the apache/nginx use case, is having the proxy module in unmanaged mode if managed mode cannot be initialized. In these use-cases we don't have multiple consumers of PKCS #11 to care about managed mode. That would also be a solution for mod_gnutls. If p11-kit cannot initialize the modules in managed mode and switches to unmanaged mode it would work. That would effectively allow the operation of p11-kit without libffi.
Well, in p11-kit we have the concept of 'enable-in' and 'disable-in' These are configuration settings that only apply for certain processes. In theory we could have a mode where all modules are unmanaged in a given process, if so configured. This is yet another solution to the problem, for you to consider.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This should be fixed in the latest package in F26.