[refpolicy] gpg domains

Christopher J. PeBenito cpebenito at tresys.com
Wed Oct 8 13:13:15 UTC 2014

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

More information about the refpolicy mailing list