From: paul.moore@hp.com (Paul Moore)
Date: Fri, 28 Aug 2009 10:48:26 -0400
Subject: [refpolicy]
 =?iso-8859-15?q?=5BRFC_PATCH_v1_2/2=5D_refpol=3A_Poli?=
 =?iso-8859-15?q?cy_for_the_new_TUN_driver_access=09controls?=
In-Reply-To: <1251462803.8357.97.camel@gorn.columbia.tresys.com>
References: <20090825210647.6250.56266.stgit@flek.lan>
	<200908271008.03693.paul.moore@hp.com>
	<1251462803.8357.97.camel@gorn.columbia.tresys.com>
Message-ID: <200908281048.26513.paul.moore@hp.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Friday 28 August 2009 08:33:23 am Christopher J. PeBenito wrote:
> On Thu, 2009-08-27 at 10:08 -0400, Paul Moore wrote:
> > On Thursday 27 August 2009 09:54:28 am Christopher J. PeBenito wrote:
> > > On Wed, 2009-08-26 at 10:32 -0400, Paul Moore wrote:
> > > > On Wednesday 26 August 2009 08:49:14 am Christopher J. PeBenito wrote:
> > > > > On Tue, 2009-08-25 at 17:12 -0400, Paul Moore wrote:
> > > > > > Add policy for the new TUN driver access controls which allow
> > > > > > policy to control which domains have the ability to create and
> > > > > > attach to TUN/TAP devices.
> > > > > >
> > > > > > +########################################
> > > > > > +## <summary>
> > > > > > +##	Allow domain to attach to admin created TUN devices
> > > > > > +## </summary>
> > > > > > +## <param name="domain">
> > > > > > +##	<summary>
> > > > > > +##	Domain allowed access.
> > > > > > +##	</summary>
> > > > > > +## </param>
> > > > > > +#
> > > > > > +interface(`userdom_tun_attach',`
> > > > > > +	gen_require(`
> > > > > > +		attribute admin_tun_type;
> > > > > > +	')
> > > > > > +
> > > > > > +	allow $1 admin_tun_type:tun_socket relabelfrom;
> > > > > > +	allow $1 self:tun_socket relabelto;
> > > > > > +')
> > > > >
> > > > > Why are only admin roles allowed to create tun_sockets?  Either the
> > > > > interface name should be changed to reflect that its not all user
> > > > > domains, or it should be expanded to cover all user domains.
> > > >
> > > > Considering the nature of TUN/TAP devices and the fact that you must
> > > > have CAP_NET_ADMIN to create a new device it seemed reasonable to
> > > > restrict the tun_socket/create permission to admin roles.  However,
> > > > we do want to allow non-admin roles the ability to attach
> > > > (tun_socket/relabel{from,to} permissions) to existing persistent
> > > > TUN/TAP devices - this is why the interface above does not have
> > > > "admin" anywhere in the name.
> > > >
> > > > Does that make sense?
> > >
> > > I'm fine with only attaching to admin domains, but the interface name
> > > needs to be changed.  Its critical that the interface names are
> > > consistent with the interface implementation.  So if the implementation
> > > is only for attaching to admin domains, the interface name has to
> > > reflect that.
> >
> > Okay, I thought the interface name was consistent based on the other
> > userdomain.if interfaces but I'm obviously missing something :)  How
> > about "admin_tun_attach"?  If that isn't right I would appreciate a
> > suggestion ...
>
> userdom_attach_admin_tun_sockets()
>
> At first I wasn't going to add sockets at the end, but
> "userdom_attach_admin_tuns()" didn't sound right to me.  The virt
> interface should be similarly changed: virt_attach_tun_sockets()

Okay.  I agree "*_admin_tuns()" sounds a little weird but sockets seems not 
quite right to me - how about "*_attach_admin_tun_iface()"?

> > > > > > diff --git a/policy/modules/system/xen.te
> > > > > > b/policy/modules/system/xen.te index 40410a7..6c4b06d 100644
> > > > > > --- a/policy/modules/system/xen.te
> > > > > > +++ b/policy/modules/system/xen.te
> > > > > > @@ -88,6 +88,7 @@ allow xend_t self:unix_dgram_socket
> > > > > > create_socket_perms; allow xend_t self:netlink_route_socket
> > > > > > r_netlink_socket_perms;
> > > > > >  allow xend_t self:tcp_socket create_stream_socket_perms;
> > > > > >  allow xend_t self:packet_socket create_socket_perms;
> > > > > > +allow xend_t self:tun_socket create;
> > > > > >
> > > > > >  allow xend_t xen_image_t:dir list_dir_perms;
> > > > > >  manage_dirs_pattern(xend_t, xen_image_t, xen_image_t)
> > > > >
> > > > > No attach?
> > > >
> > > > I'm not a Xen expert, but I assumed from discussions with some
> > > > virtualization folks that if you are running Xen then the xend_t
> > > > domain would handle the creation of any TUN/TAP devices it may need,
> > > > hence no need to attach to an existing TUN/TAP device created by
> > > > another domain. Yes?  No?
> > >
> > > I'd rather wait on adding this rule until we can get confirmation on if
> > > its needed.
> >
> > Yep, that is why I didn't add the code for attaching, just creation - or
> > are you talking about removing the creation rule too?
>
> Oh I got a little confused.  If the create is certain, then it can stay.
> The attach can be omitted until we get confirmation if its needed.

Okay.  FWIW, I'm not 100% certain about the create as I don't have working Xen 
system to test, I've included it based on discussions I've had.

-- 
paul moore
linux @ hp