selinux-refpolicy.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: dac.override@gmail.com (Dominick Grift)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH 1/1] ipsec: add missing permissions for pluto
Date: Thu, 26 Jul 2018 17:23:00 +0200	[thread overview]
Message-ID: <20180726152300.GB28965@julius.enp8s0.d30> (raw)
In-Reply-To: <20180726150656.GA28965@julius.enp8s0.d30>

On Thu, Jul 26, 2018 at 05:06:56PM +0200, Dominick Grift wrote:
> On Thu, Jul 26, 2018 at 10:58:26AM -0400, Yuli Khodorkovskiy wrote:
> > 
> > 
> > > On Jul 25, 2018, at 2:37 PM, Dominick Grift <dac.override@gmail.com> wrote:
> > > 
> > > On Wed, Jul 25, 2018 at 10:33:13AM -0400, Yuli Khodorkovskiy via refpolicy wrote:
> > >> When using libreswan, pluto needs permissions for building the
> > >> Security Association Database and for setting contexts on IPSec
> > >> policy and SAs.

A few more considerations:

1. I believe labeled-ipsec isnt supported for IKEv2 yet.
2. I believe the network_peer_controls polcap (which is enabled by default) "interferes" with some of the ipsec access vectors (there seems to be some overlap wrt send recv). You might want to consider disabling that polcap if youre just using labeled-ipsec (although not strictly needed).

> > >> 
> > > 
> > > I am fine with this, just wanted to share some considerations inline below.
> > > 
> > >> Signed-off-by: Yuli Khodorkovskiy <yuli@crunchydata.com>
> > >> ---
> > >> policy/modules/system/ipsec.te | 6 ++++++
> > >> 1 file changed, 6 insertions(+)
> > >> 
> > >> diff --git a/policy/modules/system/ipsec.te b/policy/modules/system/ipsec.te
> > >> index 867aefc4..e7ac88f2 100644
> > >> --- a/policy/modules/system/ipsec.te
> > >> +++ b/policy/modules/system/ipsec.te
> > >> @@ -212,6 +212,12 @@ domtrans_pattern(ipsec_mgmt_t, ipsec_exec_t, ipsec_t)
> > >> read_files_pattern(ipsec_mgmt_t, ipsec_t, ipsec_t)
> > >> read_lnk_files_pattern(ipsec_mgmt_t, ipsec_t, ipsec_t)
> > >> 
> > >> +# allow pluto to build Security Association Database
> > >> +ipsec_setcontext_default_spd(ipsec_t)
> > > 
> > > I would probably consider instead: corenet_setcontext_all_spds(ipsec_t)
> > > 
> > > That will make it easier to declare new spds and then associate them. You dont have to worry then about whether ipsec_t can setcontext
> > > 
> > > If its an ipsec spd then pluto can setcontext automatically
> > 
> > I like this better. I?ll send a second version.
> > 
> > > 
> > >> +
> > >> +# allow pluto to set contexts on ipsec policy and SAs
> > >> +domain_ipsec_setcontext_all_domains(ipsec_t)
> > > 
> > > This in practice could probably be limited to domains with network access. (which are nss clients as well)
> > 
> > I can?t find a network domain attribute nor an interface setcontext on network domain associations.
> 
> Yes you would have to create one yourself. Not sure its worth the trouble. Probably safer and cleaner to stick with what you have.
> 
> For example:
> 
> interface auth_setcontext_nsswitch_domains(`,'
> 	allow $1 nsswitch_domain:association setcontext;
> ')
> 
> The assumption here is that nsswitch_domain assoc. types are domains with network access.
> 
> The problem is that in reference policy this is not necessarily so. But even then, this would probably narrow things down at least a little.
> 
> Regardless. I wouldnt blame you for keeping what you have instead.
> 
> > 
> > > 
> > >> +
> > >> allow ipsec_mgmt_t ipsec_conf_file_t:file read_file_perms;
> > >> 
> > >> manage_files_pattern(ipsec_mgmt_t, ipsec_key_file_t, ipsec_key_file_t)
> > >> -- 
> > >> 2.18.0
> > >> 
> > >> _______________________________________________
> > >> 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
> > 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
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: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180726/876ae318/attachment.bin 

      reply	other threads:[~2018-07-26 15:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25 14:33 [refpolicy] [PATCH 1/1] ipsec: add missing permissions for pluto Yuli Khodorkovskiy
2018-07-25 18:37 ` Dominick Grift
2018-07-26 14:58   ` Yuli Khodorkovskiy
2018-07-26 15:06     ` Dominick Grift
2018-07-26 15:23       ` Dominick Grift [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=20180726152300.GB28965@julius.enp8s0.d30 \
    --to=dac.override@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).