Received-SPF: pass (google.com: best guess record for domain of selinux-refpolicy-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
Message-ID: <4305733.qMCtAaFjtT@liv>
In-Reply-To: <5b70567f-d551-ea5f-50e4-5febe2ad9a09@ieee.org>
References: <20200405084141.GA177560@xev> <5b70567f-d551-ea5f-50e4-5febe2ad9a09@ieee.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

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/