Bug 1271501 - p11-kit utilizes libffi which cannot be used without executable+writable memory
Summary: p11-kit utilizes libffi which cannot be used without executable+writable memory
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: p11-kit
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daiki Ueno
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1265106
Blocks: 1236526
TreeView+ depends on / blocked
 
Reported: 2015-10-14 07:44 UTC by Nikos Mavrogiannopoulos
Modified: 2017-05-02 13:47 UTC (History)
4 users (show)

Fixed In Version: p11-kit-0.23.5-1.fc26
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-02 13:47:26 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 97611 0 None None None 2017-05-02 13:47:26 UTC

Internal Links: 1243851

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.


Note You need to log in before you can comment on or make changes to this bug.