All of lore.kernel.org
 help / color / mirror / Atom feed
From: aranea@aixah.de (Luis Ressel)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH] Policy for gpg's dirmngr
Date: Wed, 28 Dec 2016 16:48:52 +0100	[thread overview]
Message-ID: <20161228164852.2fc62b0a@gentp.lnet> (raw)
In-Reply-To: <2b2c0eda-e5a2-e95e-1c2e-cdb6bbf7232d@gmail.com>

On Wed, 28 Dec 2016 16:11:54 +0100
Dominick Grift via refpolicy <refpolicy@oss.tresys.com> wrote:

> > +type gpg_dirmngr_t;
> > +type gpg_dirmngr_exec_t;
> > +typealias gpg_dirmngr_t alias { user_gpg_dirmngr_t
> > staff_gpg_dirmngr_t sysadm_gpg_dirmngr_t }; +typealias
> > gpg_dirmngr_t alias { auditadm_gpg_dirmngr_t
> > secadm_gpg_dirmngr_t };  
> 
> You do not have to typealias because I do not believe these types
> exist

Good catch!

> > +manage_dirs_pattern(gpg_dirmngr_t, gpg_secret_t, gpg_secret_t)
> > +manage_files_pattern(gpg_dirmngr_t, gpg_secret_t, gpg_secret_t)
> > +manage_lnk_files_pattern(gpg_dirmngr_t, gpg_secret_t, gpg_secret_t)
> > +manage_sock_files_pattern(gpg_dirmngr_t, gpg_secret_t,
> > gpg_secret_t)
> > +  
> 
> This would be something i would be trying to avoid. Especially with a
> process that needs to be able to connect to the network.
> 
> I think that this is probably not needed either. AFAIK, dirmngr only
> needs to maintain ~/.gnupg/crls.d (besides its socket and reading its
> ~/.gnupg/dirmngr.conf)
> 
> Ideally only the gpg process itself would be able to ever touch gpg
> secrets (files that is).

You're right; I'll change this. When gnupg 2.1 has gained a wider user
base, the whole gpg policy could use an overhaul; gpg_secret_t is
currently a catch-all type which is also used for config files and the
like. If we relabel those, we could restrict access to gpg_secret_t
further; gpg itself does not need to access the private keys (all
private keys operation are handled by gpg-agent).

> Also ideally there should not be sockets with gpg_secret_t type in the
> first place

Agreed. I probably forgot to drop that when I added the filetrans for
the S.dirmngr socket.

> sysnet_dns_name_resolve is already enclosed with auth_use_nsswitch() i
> believe (probably sysnet_use_ldap is also enclosed with
> auth_use_nsswitch() (not sure)

sysnet_dns_name_resolve() is indeed redundant. sysnet_use_ldap() is
required, though, as auth_use_nsswitch() only grants this when the
authlogin_nsswitch_use_ldap boolean is set.

Thanks for your feedback!
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/e58bcf0b/attachment.bin 

      parent reply	other threads:[~2016-12-28 15:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-28 14:58 [refpolicy] [PATCH] Policy for gpg's dirmngr Luis Ressel
2016-12-28 15:11 ` Dominick Grift
2016-12-28 15:15   ` Dominick Grift
2016-12-28 15:48   ` Luis Ressel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161228164852.2fc62b0a@gentp.lnet \
    --to=aranea@aixah.de \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.