From: dac.override@gmail.com (Dominick Grift)
Date: Fri, 10 Oct 2014 11:07:39 +0200
Subject: [refpolicy] gpg domains
In-Reply-To: <5435386B.9030801@tresys.com>
References: <1691561.ZPqvGCpHjc@russell.coker.com.au>
	<5435386B.9030801@tresys.com>
Message-ID: <1412932059.28042.41.camel@joe.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, 2014-10-08 at 09:13 -0400, Christopher J. PeBenito wrote:
> On 10/3/2014 4:47 AM, Russell Coker wrote:
> > In Debian/Testing we have the gpg-agent launching the dbus session, which then 
> > launches the user session.  So we have user_t -> gpg_agent_t -> user_dbusd_t
> >  -> user_t.  Making this work for multiple user domains requires having 
> > multiple gpg_agent_t domains (which we apparently used to have).
> > 
> > Removing the multiple $1_gpg_t domains without removing the 
> > user_t/unconfined_t/staff_t split doesn't seem to be viable.
> > 
> > Also why do we have gpg_agent_t, gpg_helper_t, and gpg_pinentry_t?  What 
> > benefit does this give us over having a single domain for GPG stuff that's other 
> > than gpg_t?  What is the logic behind a gpg_pinentry_t/gpg_agent_t anyway?  
> > Are those things that can even be properly split?
> 
> I did some analysis, and it looks like the main gpg_agent_t difference
> from gpg_t is not having any network access.  Since gpg_agent_t is long
> running and gpg_t isn't, I'd be inclined to keep it separate.
> 
> gpg_pinentry_t is typically short running like gpg_t and doesn't seem to
> have significant differences other than the X-related perms, so I could
> see gpg_pinentry_t potentially being folded back into gpg_t.
> 
> I'm not sure about gpg_helper_t, as I'm not familiar with the gpgkeys.*
> commands.  Based on the policy, I'm guessing that the gpg helper is/was
> for separating out the network permissions from the gpg main process, so
> the process with network access (e.g. to pull public keys from a network
> server) was separated from the process with gpg secrets access.  That
> separation seems to have broken down over time, so the domain could
> probably be dropped.
> 

I think this a a pretty good assessment.

In practice pinentry is only ever executed by gpg-agent but in theory, i
suppose, it could be used by other processes. The only notable operation
aside from the permissions associated with pinentry-qt and pinentry-gtk
is that it stream connects to gpg-agent (or i suppose any process
calling it)

The gpgkeys-hkp, gpgkeys-ldap, and probably gpgkeys-curl indeed connect
to the network, and i suspect that if may be possible and maybe feasible
to make gpg_t run those with a domain transition. I have not tested
this.

I suspect that it, if anything, only maintains
~/.gnupg/private-keys-vN.d/ and so one may or may not be able to cut off
network access to the gpg private keys entirely. To my surprise, i have
not tried this myself (i allow processes running in the gpg_t domain to
execute these applications, and thus i allow gpg_t to connect to the
network), but i may do so in the near future.

It might also be feasible to confine scdaemon, which is a long running
session daemon started by gpg-agent that deals with the smartcard
functionality. It in turn runs another long lived program that
communicates with pcscd

The scdaemon maintains a sock file in /tmp and a file in ~/.gnupg

I suppose that if one does not mind to extent gpg-agent domain with the
various permissions associated with pinentry-qt and pinentry-gtk
(xserver related) that it may be feasible to just allow gpg-agent to run
pinentry in the gpgagent domain.

I personally would not run scdaemon in the gpg-agent domain, although i
suppose i cannot really come up with an compelling argument other than
that it is a another long running process that is optional (only used
with smartcards)

scdaemon, gpg-agent, gpg, and probably the gpgkeys helpers maintain
content in ~/.gunpg, anything else, except i suppose useradd_t for
userdel -r, has no business in ~/.gnupg i believe

I my personal policy i have private domains for pinentry, scdaemon,
gpgpcscd, gpgagent, and gpg. It is a bit too much separation i suppose
to justify, but access to the private keys is pretty much restricted to
the gpg domain.

If i can only split the network access out of gpg and disallow the
gpgkeys tools access to the private keys... (i should try that)