Bug 636152 - RFE: secrets: encrypt the local secrets data files
Summary: RFE: secrets: encrypt the local secrets data files
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
: 1017273 (view as bug list)
Depends On:
Blocks: libvirtTodoSecurity
TreeView+ depends on / blocked
 
Reported: 2010-09-21 15:09 UTC by Daniel Berrangé
Modified: 2020-11-03 16:15 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-11-03 16:15:23 UTC
Embargoed:


Attachments (Terms of Use)

Description Daniel Berrangé 2010-09-21 15:09:46 UTC
Description of problem:
The secrets driver simple obscures secrets using base64. It should be possible to encrypt them using a master password, which libvirtd obtains from a secure location or TPM.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Cole Robinson 2016-04-10 15:01:37 UTC
*** Bug 1017273 has been marked as a duplicate of this bug. ***

Comment 2 Cole Robinson 2016-04-10 15:02:23 UTC
From the other RFE

Description of problem:
Currently libvirt stores persistent secrets in unencrypted files in /etc/libvirt/secrets.  This is not a big security problem since the virtualization host fundamentally must be a trusted component. The secrets are about protecting against rogue storage admins, and/or authenticating with network storage.

It would still, however, be desirable to have the secrets stored encrypted to at least make a dedicated forensics attacker have todo some non-trivial work to recover them, even when the HD itself is not encrypted.

We could probably leverage something like pkcs11 as a secure storage mechansim to do this. There might be good enough support in gnutls APIs to do this. TBD.

Comment 3 Daniel Berrangé 2020-11-03 16:15:23 UTC
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.


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