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?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
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
http://www.tresys.com | 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)