Bug 1271501

Summary: p11-kit utilizes libffi which cannot be used without executable+writable memory
Product: [Fedora] Fedora Reporter: Nikos Mavrogiannopoulos <nmavrogi>
Component: p11-kitAssignee: Daiki Ueno <dueno>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: kengert, mpreisle, stefw, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: p11-kit-0.23.5-1.fc26 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-02 13:47:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1265106    
Bug Blocks: 1236526    

Description Nikos Mavrogiannopoulos 2015-10-14 07:44:38 UTC
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

Comment 1 Stef Walter 2015-10-14 07:50:08 UTC
> 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.

Comment 2 Nikos Mavrogiannopoulos 2015-10-14 08:11:31 UTC
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.

Comment 3 Tomas Mraz 2015-10-14 08:50:51 UTC
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.

Comment 4 Nikos Mavrogiannopoulos 2015-10-14 11:28:42 UTC
(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.

Comment 5 Stef Walter 2015-10-14 19:21:34 UTC
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.

Comment 6 Nikos Mavrogiannopoulos 2015-10-15 06:55:43 UTC
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.

Comment 7 Stef Walter 2015-10-16 08:56:50 UTC
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.

Comment 8 Jan Kurik 2016-02-24 13:50:32 UTC
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

Comment 9 Jan Kurik 2016-07-26 05:05:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 10 Fedora End Of Life 2017-02-28 09:49:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 11 Fedora Admin XMLRPC Client 2017-04-26 13:56:47 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Daiki Ueno 2017-05-02 13:47:26 UTC
This should be fixed in the latest package in F26.