Bug 1693356

Summary:	fprintd: stores user fingerprints as image files without encryption
Product:	[Other] Security Response	Reporter:	Laura Pardo <lpardo>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	bnocera, sungjungk
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-04-09 05:54:03 UTC	Type:	---
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:	1693357
Bug Blocks:	1693359

Description Laura Pardo 2019-03-27 16:02:38 UTC

It was found that fprintd saves fingerprint data, in ISO/IEC 19794-2 format and without any encryption, to a file with root permission on the host. This could allow a privileged process to access the stored fingerprint.


Upstream Bug:
https://gitlab.freedesktop.org/libfprint/fprintd/issues/16

Comment 1 Laura Pardo 2019-03-27 16:02:52 UTC

Created fprintd tracking bugs for this issue:

Affects: fedora-all [bug 1693357]

Comment 2 Laura Pardo 2019-03-28 13:12:08 UTC

Acknowledgments:

Name: Seong-Joong Kim

Comment 4 Huzaifa S. Sidhpurwala 2019-04-09 05:54:03 UTC

The fprintf daemon in Red Hat Enterprise Linux is contained by the default installed selinux policy. This prevents other applications (which dont need access to fingerprint data) from accessing this fingerprint data and therefore ensures a good level of security for the same. 

Also as per upstream: https://gitlab.freedesktop.org/libfprint/fprintd/issues/16#note_141207 
such an LSM based security system should be enough to safeguard this data. And there is no short term plan for any other implementation.

Based on above, Red Hat Product Security does not believe this to be a security flaw.

Comment 5 Seong-Joong Kim 2019-04-11 05:21:24 UTC

I don’t think it would be as good.
Particularly, desktop users usually disable or change it to permissive mode in SELinux.
Instead, how about trying to add user authentication while attempting to access the fingerprint data?
It would be possible to apply it since the fingerprint data is separately located in different path (e.g., /var/lib/username/device-id/XXX).

Comment 6 Seong-Joong Kim 2019-04-12 09:55:27 UTC

Under such a scenario, I think it is not justifiable to shift protection responsibility to OS entirely.

Instead, we need to devise a data encryption/protection scheme at least.

This issue can be even more important than password exposure in cleartext.

Because once fingerprint has been leaked, victims are leaked for the rest of life since it lasts for a life.

What do you think of it?