From: Dominick Grift <dominick.grift@defensec.nl>
To: Russell Coker <russell@coker.com.au>
Cc: Chris PeBenito <pebenito@ieee.org>, selinux-refpolicy@vger.kernel.org
Subject: Re: new certbot patch
Date: Fri, 10 Apr 2020 09:55:16 +0200 [thread overview]
Message-ID: <ypjlblnzn5az.fsf@defensec.nl> (raw)
In-Reply-To: <4305733.qMCtAaFjtT@liv> (Russell Coker's message of "Fri, 10 Apr 2020 15:56:26 +1000")
Russell Coker <russell@coker.com.au> 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@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
next prev parent reply other threads:[~2020-04-10 8:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-05 8:41 new certbot patch Russell Coker
2020-04-09 13:23 ` Chris PeBenito
2020-04-10 5:56 ` Russell Coker
2020-04-10 7:55 ` Dominick Grift [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-02-19 2:34 Russell Coker
2020-02-19 20:51 ` Chris PeBenito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ypjlblnzn5az.fsf@defensec.nl \
--to=dominick.grift@defensec.nl \
--cc=pebenito@ieee.org \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).