From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 19 Sep 2014 14:37:28 -0400
Subject: [refpolicy] cert_t
In-Reply-To: <20140918142842.GA10806@x220.network2>
References: <201409131443.09899.russell@coker.com.au>	<20140917180047.GA11344@meriadoc>
	<541ADE06.9000208@tresys.com>
	<20140918142842.GA10806@x220.network2>
Message-ID: <541C77E8.5050507@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 9/18/2014 10:28 AM, Dominick Grift wrote:
> 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'm not requiring any changes.  If the proposed change doesn't work,
then I'm fine making no changes.

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