[refpolicy] gpg domains

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

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.

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