From: Russell Coker <russell@coker.com.au>
To: Chris PeBenito <pebenito@ieee.org>
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: new certbot patch
Date: Fri, 10 Apr 2020 15:56:26 +1000 [thread overview]
Message-ID: <4305733.qMCtAaFjtT@liv> (raw)
In-Reply-To: <5b70567f-d551-ea5f-50e4-5febe2ad9a09@ieee.org>
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.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
next prev parent reply other threads:[~2020-04-10 5:56 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 [this message]
2020-04-10 7:55 ` Dominick Grift
-- 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=4305733.qMCtAaFjtT@liv \
--to=russell@coker.com.au \
--cc=pebenito@ieee.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.