Russell Coker <russell@xxxxxxxxxxxx> writes: > On Thursday, 9 April 2020 11:23:00 PM AEST Chris PeBenito wrote: >> > +miscfiles_read_generic_certs(certbot_t) >> > +miscfiles_manage_generic_tls_privkey_dirs(certbot_t) >> > +miscfiles_manage_generic_tls_privkey_files(certbot_t) >> > +miscfiles_manage_generic_tls_privkey_lnk_files(certbot_t) >> >> Perhaps we should be moving towards having a specific label for these >> private keys instead. It seems logical that there would be multiple types >> of private keys. Then have a miscfiles_private_key() to declare one and >> have the type in this module to act on directly. > > Certbot isn't written to support different runs on the same system. It might > be worth filing an upstream feature request for that as it would be a useful > feature. > > As for SE Linux policy to support multiple separate private SSL keys on the > same system, it seems that there would be many variations on that and trying > to write generic policy wouldn't be viable. Maybe a better solution would be > to support different MCS categories for different daemons and then different > categories for private keys. Then the sysadmin would have full control over > which daemons could access which private keys. A more practical approach here in my experience is to not give access to certs in /etc/letsencrypt but let the hook functionality copy the certs from the store and then address labeling with "cert_type()" in the accessible location. Not ideal either but the way letsencrypt maintains its certs in /etc/letsencrypt is not very usable either. Eventually one might end up altering/combining the certs anyway's. For example znc seems to require that you enclose the privkey with the chain. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
