From: jason@perfinion.com (Jason Zaman)
Date: Thu, 18 Sep 2014 02:00:47 +0800
Subject: [refpolicy] cert_t
In-Reply-To: <201409131443.09899.russell@coker.com.au>
References: <201409131443.09899.russell@coker.com.au>
Message-ID: <20140917180047.GA11344@meriadoc>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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?

-- Jason

> -- 
> My Main Blog         http://etbe.coker.com.au/
> My Documents Blog    http://doc.coker.com.au/
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy