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
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.
SSLCertificateKeyFile
SSLPassPhraseDialog
Metadata Update from @stlaz: - Issue assigned to stlaz
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.
system_u:object_r:httpd_passwd_exec_t:s0
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.
/usr/libexec/httpd-ssl-pass-file server:port keytype
/var/lib/httpd/passphrases/host-port-keytype
/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
httpd_exec_t
/var/lib/ipa/certs/$PASSWORD
httpd_passwd_exec_t
/var/lib/ipa/certs
certmonger_exec_t
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.
$PASSWORD
/etc/pki/tls
cert
private
password
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:
Metadata Update from @cheimes: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @pvoborni: - Issue set to the milestone: FreeIPA 4.7
Login to comment on this ticket.