[refpolicy] cert_t

[dac.override@gmail.com (Dominick Grift)]

On Thu, Sep 18, 2014 at 09:28:38AM -0400, Christopher J. PeBenito wrote:
> 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.
> 

I also like the idea of tightening access to the private key but i see some potential issues

For one, i suspect that one can have multiple private keys in there. If true then this makes it
hard to use named-based file type transitions for the private keys

A hack would be to create name-based file type transitions for anything *but* the private keys instead
however this is probably just as prone to error.

The question also arises, to what end?

We've spoken about this and it turns out, i believe, that OP wants to disallow at least read access to the user domain
associated with the user owning the file.

My reply to that was that the main reason for such a requirement probably is that so many programs currently run in the user domain, and
that it would not so much be a problem if the user himself could read the file

This leads me to believe that this implementation is more of a cure for a symptom rather than a cure for the root of the problem, namely
(long running) processes running in the user domain that have access to the file.

In practice very few programs need access to ~/.gnupg regular files at least. One of them is gpgagent which in refpolicy is also covered
gpgagent needs to be able to read and maybe even maintain gpg-agent.conf as well as be able to maintain a gpg-agent socket in there

There are a few other exceptions like gnupg scdaemon.

In conclusion. In my view the fix to the problem is to target user agents instead, and disallow user agents access to regular files with type gpg_secret_t
however i realize that this is probably an unachievable goal in a general purpose policy (we cant predict what programs are run by users, and we dont have the
man power to target all conceivable threats in the user session))

Preventing the user domain associated with the user owning they key access to the key in any way sounds like a sub-optimal solution.

All in all i see difficulties implementing this, and it appears to me as a bit of an ugly hack

As someone who has been advocating for integrity in the user session i obviously agree with the assessment that currently too many processes have to much access to
sensitive files like these.

It's just this solution that i do not really like.

But if the maintainer wants it then i will be happy to commit it either way because i know that with the territory of general purpose comes compromise, and i will
be willing to compromise.

I just want everyone to understand the pro's and con's of this "solution". 

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://subkeys.pgp.net:11371/pks/lookup?search=0x02DFF788&op=index
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140918/d98b5856/attachment.bin