[refpolicy] gpg policy

[refpolicy] gpg policy

[Luis Ressel]

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

[refpolicy] gpg policy

[Dominick Grift]

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 

[refpolicy] gpg policy

[Luis Ressel]

On Wed, 28 Dec 2016 17:40:39 +0100
Dominick Grift via refpolicy <refpolicy@oss.tresys.com> 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