#7421 Store HTTPD private keys encrypted
Closed: fixed 5 years ago Opened 6 years ago by stlaz.

Since FreeIPA is using mod_ssl as an HTTPD SSL backend now, its private keys are being stored as files in the filesystem. To improve security in case such a file is compromised, we should have the keys encrypted by a password.

mod_ssl allows having its SSLCertificateKeyFile in encrypted form but for our use-case, we would need this to be automatically decrypted by a binary provided in the SSLPassPhraseDialog directive in mod_ssl configuration file.


Metadata Update from @stlaz:
- Issue assigned to stlaz

6 years ago

A few comments

Passphrase dialog executables must have SELinux context system_u:object_r:httpd_passwd_exec_t:s0. All files and directories must be accessible and readable by the context, too. Please keep this in mind and file a SELinux bug.

SSLPassPhraseDialog is a highlander option (there can only be one). I'd prefer to solve the issue in mod_ssl and have it include a simple bash script that maps arguments to file names, e.g. /usr/libexec/httpd-ssl-pass-file server:port keytype reads from phrase from /var/lib/httpd/passphrases/host-port-keytype. FreeIPA would just have to dump the passphrase into /var/lib/httpd/passphrases/$fqdn-443-RSA.

Let's see how SELinux policies must be defined:

  • /var/lib/ipa/certs/httpd.crt, /var/lib/ipa/certs/httpd.key and parent directories must be readable by httpd_exec_t
  • /var/lib/ipa/certs/$PASSWORD and parent directories must be readable by httpd_passwd_exec_t
  • httpd_passwd_exec_t must not be allowed to write to /var/lib/ipa/certs or read the key file.
  • /var/lib/ipa/certs/httpd.crt, /var/lib/ipa/certs/httpd.key and parent directories must be readable and writeable by certmonger_exec_t
  • /var/lib/ipa/certs/$PASSWORDmust be readable by certmonger_exec_t
  • Others contexts may read the cert file but must not be able to read key and password file. No other context must be allowed to modify the files.

The dynamic nature of $PASSWORD file name and different access levels for key, cert and password makes it hard to implement a proper SELinux policy. I'd either drop the certs into /etc/pki/tls or use a similar directory structure with cert, private and password subdirs.

I think we should go with mimicking the dir structure of /etc/pki/tls.

Please, before moving forward explain 3 things:
a) Exactly what is the threat model
b) How this solution addresses the threat model
c) Why this solution is the only/best mitigation

4 things:
d) Why is IPA disregarding the packaging guide for mod_ssl certs and keys? https://docs.fedoraproject.org/quick-docs/en-US/getting-started-with-apache-http-server.html

@cheimes originally requested this feature so he may bring some more and better answers. But let me try first, then.

I don't think this should directly protect us from some threats except for human mistakes. When the private key is shared/leaks by an accident of a user, it's still not very useful as long as it's encrypted.

Is it the only/best mitigation agains this? Not sure.

as for d), that is simple - since we provide means to changing the content, I don't want to have it in /etc. We've had enough dynamic symlink creations to /etc in the container use-case, we don't need more.

In what case an accidental leak of a key won't go with the accidental leak of the password file as well ?

IIRC we must encrypt any private key material for FIPS compliance. The private key can have a different SELinux type as the password file. Apache HTTPD doesn't need to be able to read the password file. Only certmonger and the SSLPassPhraseDialog tool need read access for the password file.

Christian,
how does apache use the key if it has no access to the encryption password ?
Via a "privileged" helper ?

Yes, the SSLPassPhraseDialog helper tool runs with a different SELinux context than the Apache HTTPD server. The tools is invoked for every encrypted private key and returns the symmetric password on stdout.

TBH I would consider using clevis/tang instead of password protecting the cert, but either way works for me, although I do not find this issue to be a priority in general.

master:

  • 7cbd9bd Encrypt httpd key stored on disk

Metadata Update from @cheimes:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 years ago

master:

  • 47cf159 Fix upgrading of FreeIPA HTTPD
  • e707d97 ipa_backup: Backup the password to HTTPD priv key

Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.7

5 years ago

Login to comment on this ticket.

Metadata