2016-12-28 16:32:33

by Mira Ressel

[permalink] [raw]
Subject: [refpolicy] gpg policy

I'm currently trying to re-write the contrib/gpg module a bit. In
particular, I intend to change the types used for the data in
~/.gnupg/. This is what I have in mind:

* .gnupg/ itself: gpg_home_t (all gpg-related programs can create
files/directories inside this)
* .gnupg/*.conf: gpg_conf_t (all gpg-related programs can read, but not
write, those files)
* .gnupg/{trustdb.gpg,pubring*} and similar: gpg_home_t (only gpg_t
can manage those files; perhaps I'll need to allow other gpg-related
tools read access)
* .gnupg/* (everything else): gpg_secret_t (only gpg_t and gpg_agent_t
can manage those files)

With gnupg 2.1, only gpg_agent_t needs access to gpg_secret_t data;
perhaps I'll add a boolean to configure this.

Any thoughts?

Regards,
Luis


2016-12-28 16:40:39

by Dac Override

[permalink] [raw]
Subject: [refpolicy] gpg policy

On 12/28/2016 05:32 PM, Luis Ressel via refpolicy wrote:
> I'm currently trying to re-write the contrib/gpg module a bit. In
> particular, I intend to change the types used for the data in
> ~/.gnupg/. This is what I have in mind:
>
> * .gnupg/ itself: gpg_home_t (all gpg-related programs can create
> files/directories inside this)
> * .gnupg/*.conf: gpg_conf_t (all gpg-related programs can read, but not
> write, those files)
> * .gnupg/{trustdb.gpg,pubring*} and similar: gpg_home_t (only gpg_t
> can manage those files; perhaps I'll need to allow other gpg-related
> tools read access)
> * .gnupg/* (everything else): gpg_secret_t (only gpg_t and gpg_agent_t
> can manage those files)
>
> With gnupg 2.1, only gpg_agent_t needs access to gpg_secret_t data;
> perhaps I'll add a boolean to configure this.

I am a bit confused about what you consider gpg_secret_t data.

gpg creates/maintains the private key. This is the thing I would want to
protect. Only gpg itself ever needs access to that file. Thus no
confined application should ever have any access to this private key

>
> Any thoughts?
>
> Regards,
> Luis
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>


--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161228/3b044528/attachment.bin

2016-12-28 16:48:56

by Mira Ressel

[permalink] [raw]
Subject: [refpolicy] gpg policy

On Wed, 28 Dec 2016 17:40:39 +0100
Dominick Grift via refpolicy <[email protected]> wrote:

> I am a bit confused about what you consider gpg_secret_t data.
>
> gpg creates/maintains the private key. This is the thing I would want
> to protect. Only gpg itself ever needs access to that file. Thus no
> confined application should ever have any access to this private key

I guess my wording wasn't precise enough. By "gpg-related program", I
mean gpg, gpg-agent, dirmngr and scdaemon.

I don't want to expose any data in ~/.gnupg to third-party programs.
I'm just trying to segregate the different components of gpg (the tools
mentioned above) from each other; for example, as you remarked in your
previous mail, dirmngr shouldn't have access to private key material.

Regards,
Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161228/6562cfde/attachment.bin