From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 15 Sep 2014 15:26:36 -0400
Subject: [refpolicy] cert_t
In-Reply-To: <201409131443.09899.russell@coker.com.au>
References: <201409131443.09899.russell@coker.com.au>
Message-ID: <54173D6C.7010006@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 9/13/2014 12:43 AM, Russell Coker wrote:
> What's the point of cert_t?  It's used for private keys as well as config 
> files such as openssl.cnf which don't seem particularly secret.

I don't think it's as much for keeping things secret but rather to
constrain who can write to it, instead of letting it be etc_t or
something similar.  That being said, having openssl.cnf being cert_t is
probably overspecified, and we should probably keep cert_t to
certificates and other key materials.


> What is the aim of it?  Should it be just used for the secret files (EG 
> /etc/ssh/private/*)?
> 
> Currently the ssh client fails on Debian/Unstable because ssh_t isn't 
> permitted to access cert_t.  Audit2allow tells me that enabling the boolean 
> authlogin_nsswitch_use_ldap would permit such access which suggests that we 
> might have further problems with cert_t.  Presumably allowing LDAP 
> authentication shouldn't mean that network facing programs such as the ssh 
> client get to read SSL private keys.
> 

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com