[refpolicy] [PATCH 1/2] Policy for gpg's dirmngr

[dac.override@gmail.com (Dominick Grift)]

On Mon, Aug 10, 2015 at 03:42:34PM +0200, Luis Ressel wrote:

<snip>

> > 
> > It does not seem to actually maintain temporary files. Instead it
> > maintains content in ~/.gnupg. So classifying that type
> > userdom_user_tmp_file is inaccurate in my view
> > 
> 
> Yes, I only needed gpg_dirmngr_tmp_t for the socket file, it's not used
> for anything in /tmp. I'll change the declaration. Should I also change
> the name to something other than _tmp_t?

I would probably change the name of the type but i don' t find the name as important. What i do find more important is that this type is not actually associated with user tmp files but instead with user home files.

> > 
> > I do not believe that dirmngr needs to be able to maintain gpg
> > secrets. (I am pretty sure about that)
> > 
> 
> It does not need access to the secret files, just the config files
> and .gnupg/{dirmngr-cache,crls}.d/, which are currently labeled
> gpg_secret_t (also, the .gnupg/ directory itself has this type). I'll
> improve this.

I wasnt aware of ~/.gnupg/dirmngr-cache.d ..  but yes that and crls.d would need to be associated with the dirmngr type and not the gpg secret type in my view

Yes it needs to traverse ~/.gnupg obviously and add/del ~/.gnupg directory entries but ideally it should not need any access to any file in ~/.gnupg other than its own (we dont want it to be able to access the keys for example)

> > 
> > I was not able to confirm the above two instead thoug it wants to
> > read crypto sysctls here
> > 
> 
> On my system, dirmngr fails to start without those.
> 
> avc:  denied  { read } for  pid=2126 comm=636F6E6E2066643D30
> name="random" dev="devtmpfs" ino=1032
> scontext=staff_u:staff_r:gpg_dirmngr_t
> tcontext=system_u:object_r:random_device_t tclass=chr_file permissive=0
> 

Assuming 636F6E6E2066643D30 translates to "dirmngr", then i guess it is needed. I havent encountered this on my implementation.

> > 
> > I think that this may be a bit too much. I suppose it needs to be
> > able to hkp and http ports instead?
> 
> The network permissions are in fact a bit wide, it only needs access to
> hkp, http and ldap. However, the same could be said about gpg_t and
> gpg_agent_t (I copied the permissions from their policies).
> 

The existing gpg policy is not optimal and i wouldnt take that as an example. In fact I would revisit the whole gpg suite because
gpg agent doesnt need access to gpg secrets either. The main goal of this policy, in my view, is to ensure integrity of the keys.

> -- 
> Luis Ressel
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20150810/2e8baf24/attachment-0001.bin