[refpolicy] cert_t

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 9/17/2014 2:00 PM, Jason Zaman wrote:
> On Sat, Sep 13, 2014 at 02:43:09PM +1000, 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.
>>
>> 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.
> 
> This reminded me of something similar, I've actually been wondering
> about gpg_secret_t.
> 
> HOME_DIR/\.gnupg(/.+)?  gen_context(system_u:object_r:gpg_secret_t,s0)
> 
> the dir does not seem particularly secret, gpg.conf and gpg-agent.conf
> etc. On the other hand, the secring.gpg is *very* secret. There are
> quite a lot of things on my machine that can read gpg_secret_t files.
> 
> Ideally i would think there should be a gpg_home_t for the dir and then
> the secring is gpg_secret_t and access to gpg_secret_t should be
> removed. I dont see why anything other than gpg should be able to read
> the file. Should i send a patch to do this? or is there a reason it is
> how it is that i am unaware of?

To clarify, you mean everything in the directory is gpg_home_t, except
for the private keys, which are gpg_secret_t?  If so, that sounds
reasonable.

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