Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Fri, Sep 30, 2016 at 03:59:55PM -0400, Paul Moore wrote:
> > We also have iwarp vs rocee where AFAIK iwarp should get the vlan tag
> > from the IP socket that is allocated against the eth interface.
> 
> Sigh.
> 
> So we've got RDMA over IB (does this have an acronym?  my googling

We just call that IB

> isn't showing anything ...), RoCEv1 which appears to be RDMA over

Technically (IIRC) RoCEv1 is exactly the IB protocol with an ethernet
MAC header tacked in front. It even has a slot for a pkey value, but
no switches will inspect it.

> Ethernet (although it looks like it might still use an IP header?),

The 'IP' header is a IB GRH which is identical to a IPv6 header. We
call the IPv6 address in this header a GID.

> RoCEv2 which appears to be RDMA over UDP, and iWARP which seems to be
> RDMA over TCP/SCTP.  Are there any others?

RoCEv2 is the IB protocol with a UDP header added in.

iWARP is a unique protocol that runs RDMA inside TCP.

> We've already talked about the RDMA/IB's pkeys and RoCEv1's GID/VLANs,
> but RoCEv2 and iWARP are a little more interesting as they ride on top
> of a routable network transport.  Do RoCEv2 and iWARP use the kernel's
> stack, or is that off-loaded?

Gernally all off-loaded. There is one software implementation but it
is not used for anything serious. Well, maybe two IB drivers don't
offload this, I'm not sure.

> Actually, now that I think of it, RoCEv2 and iWARP are probably
> implemented as userspace libraries aren't they?

Nope, there is a userspace library component, but the kernel is
largely in charge. They are sort of distinct from the netstack, but
part of the RDMA stack. It is very confusing because netdev is
ideologically opposed (for good reason) to any form of offload, so
even though these devices use the same physical network port, and use
IP headers, they are not very well integrated.

Eg iwarp calls out to a userspace process which opens a socket to
reserve a port number and then feeds that back into the kernel to
setup IP headers which are safe to use. :\ The nic steals those
packets before the kernel ever sees them and processes them with an
internal 'CPU' and then feeds the QP infrastructure. (this is what is
ment by the term offload)

This also means that likely all the SE linux protections that apply to
ethernet are merrily voided by all this offload hardware and AFAIK
nobody has done any work to try and do something about that.

So Liran is right, when we talk about iWarp/RoCEv2 the SELinux stuff
should follow the ethernet stack.

However, every IB port typically has some number of child ipoib
netdevices as well, and those devices also specify a Pkey. This is
where the namespace patches source their pkey information from. I
don't know why a different approach is proposed for selinux. (Well,
aside from the fact the namespace patches were never completed and
basically don't work for strong isolation..)

.. and that is my basic concern, that selinux will get one patch
series and be left essentially incomplete like namespaces were.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Thu, Sep 08, 2016 at 06:59:13PM +, Daniel Jurgens wrote:

> >> Net has variety of means of enforcement, one of which is controlling
> >> access to ports , which is the most like what
> >> I'm doing here.
> > No, the analog the tcp/udp,port number is  

> I should have been clearer here.  From the SELinux perspective this
> scheme is very similar to net ports.

It really isn't. net ports and service_ids are global things that do
not need machine-specific customizations while subnet prefix or device
name/port are both machine-local information.

> >> with this aside from it being where the policy is stored before
> >> being loaded.  What is this dynamic injector you are talking about?
> > The container projects (eg docker) somehow setup selinux on the
> > fly for each container. I'm not sure how.

> SELinux policy is modular and can be changed or updated while
> running, I'm not very familiar with docker so I'm not sure what they
> do regarding SELinux.  I'm also not sure it's relevant to the issues
> at hand.

docker and the like would seem to be the #1 user of this kind of
feature, it goes hand in hand with the ipoib namespace work that does
a similar (but less complete thing). This is a great way to create a
container and constrain it to a single pkey/vlan/ipoib device, which
would be the basic capability needed to sensibly rdma and containers
together.

This is why thinking about how to fully support the pkey/vlan concept
across all the rdma drivers seems so critical.

I'm surprised this isn't your use case. Again, I wish you'd think more
broadly before designing new uapis. selinux enabling the rdma
subsystem is a whole new uapi aspect for rdma that we have to live
with forever.

> >> called mlx5_0, the another mlx4_0 and you want to grant access to
> >> system administrators.
> > So do this in userspace? Why should the kernel do the translation?

> I'm still not clear on what translation you are talking about.

Converting the subnet prefix to a list of physical ports.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Thu, Sep 08, 2016 at 05:47:46PM +, Liran Liss wrote:

> This patch-set enables partition-based isolation for Infiniband networks in a 
> very intuitive manner, that's it.
> IB partitions don't have anything to do with VLANs.

You guys need to do a better job at supporting the whole subsystem
when you propose new uapi features.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Thu, Sep 08, 2016 at 04:44:36PM +, Daniel Jurgens wrote:

> Net has variety of means of enforcement, one of which is controlling
> access to ports , which is the most like what
> I'm doing here.

No, the analog the tcp/udp,port number is  

> It will work like any other SELinux policy.  You label the things
> you want to control with a type and setup rules about which
> roles/types can interact with them and how.  I'm sure the default
> policy from distros will be to not restrict access.  Policy is
> loaded into the kernel, the disk and filesystem has nothing to do

Eh? I thought the main utility of selinux was using the labels written
to the filesystem to constrain access, eg I might label
/usr/bin/apache in a way that gets the  policy applied to it.

> with this aside from it being where the policy is stored before
> being loaded.  What is this dynamic injector you are talking about?

The container projects (eg docker) somehow setup selinux on the
fly for each container. I'm not sure how.

> Assume you have machines on one subnet (0xfe80::) one has a device
> called mlx5_0, the another mlx4_0 and you want to grant access to
> system administrators.

So do this in userspace? Why should the kernel do the translation?

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Thu, Sep 08, 2016 at 02:12:48PM +, Daniel Jurgens wrote:

> It would have to include the port, but idea of using a device name
> for this is pretty ugly.   makes it very easy to
> write a policy that can be deployed widely.  
> could require many different policies depending on the configuration
> of each machine.

What does net do? Should we have a way to unformly label the rdma ports?

How do you imagine these policies working anyhow? They cannot be
shipped from a distro. Are these going to be labeled on filesystem
objects? (how doe that work??) Or somehow injected when starting a
container?

If they are not written to disk I don't see the problem, the dynamic
injector will have to figure out what interface is what.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Tue, Sep 06, 2016 at 08:35:56PM +, Daniel Jurgens wrote:

> I think to control access to a VLAN for RoCE there would have to
> labels for GIDs, since that's how you select which VLAN to use.

Since people are talking about using GIDs for containers adding a GID
constraint for all technologies makes sense to me..

But rocev1 (at least mlx4) does not use vlan ids from the GID, the
vlan id is set directly in the id, so it still seems to need direct
containment. I also see vlan related stuff in the iwarp providers, so
they probably have a similar requirement.

> required.  RDMA device handle labeling isn't granular enough for
> what I'm trying to accomplish.  We want users with different levels
> of permission to be able to use the same device, but restrict who
> they can communicate with by isolating them to separate partitions.

Sure, but maybe you should use the (device handle:pkey/vlan_id) as your
labeling tuple not (Subnet Prefix, pkey)

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Tue, Aug 30, 2016 at 07:10:12PM +, Daniel Jurgens wrote:
> On 8/30/2016 1:56 PM, Jason Gunthorpe wrote:
> >
> > Are subsystems usually SELinux enabled in such a piecemeal way?
> >
> > Are you sure the 'partition' SELinux label should not be more general
> > to cover more of the similar RDMA cases?

> In order to label something you have to be able to describe
> something unique about an instance of it, like a Subnet Prefix/PKey
> value pair.  What other thing could we label more generally to
> control access to a partition/VLAN?

IP prefix / vlan #? How does it work in net?

Shouldn't you at least have a plan for how this will expand to cover
the whole subsystem??

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Tue, Aug 30, 2016 at 06:52:28PM +, Daniel Jurgens wrote:
> On 8/30/2016 1:46 PM, Jason Gunthorpe wrote:
> > On Tue, Aug 30, 2016 at 02:06:53PM +, Daniel Jurgens wrote:
> >
> >> I don't this will be useful, RoCE doesn't have partitions/PKeys
> >> because it uses Ethernet as the transport instead of Infiniband.
> > The vlan stuff in roce should be just as restricted as the pkey is in
> > IB

> This patch set introduces a mechanism for controlling access to
> Infiniband partitions.  If someone is interested in writing SELinux
> tests regarding RoCE and VLANs then RXE may very well be useful for
> them.  It just doesn't apply here.

Are subsystems usually SELinux enabled in such a piecemeal way?

Are you sure the 'partition' SELinux label should not be more general
to cover more of the similar RDMA cases?

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v3 0/9] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Tue, Aug 30, 2016 at 02:06:53PM +, Daniel Jurgens wrote:

> I don't this will be useful, RoCE doesn't have partitions/PKeys
> because it uses Ethernet as the transport instead of Infiniband.

The vlan stuff in roce should be just as restricted as the pkey is in
IB

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC PATCH v2 00/13] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Tue, Apr 12, 2016 at 05:06:45PM +, Hefty, Sean wrote:
> > Wouldn't QP1 require different access control than QP0 due to SA clients
> > on every end node ?
> 
> QP1 still allows modification of the fabric (e.g. multicast join) or
> an DoS attack against the SA.  Though the latter probably requires
> restricting how a UD QP may be used.

Right, I don't disagree we should have smp and gmp 'just in case'
(fine names as well) labels, I just don't really understand why you'd
trust something enough to grant gmp but not enough for smp...

Particularly encouraging people to grant gmp as though that was 'safe'
is really bad advice.

Which in turn makes me wonder why the umad dev node label is not
sufficient.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC PATCH v2 00/13] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Mon, Apr 11, 2016 at 11:35:57PM +, Daniel Jurgens wrote:

> OK, I'll change idbev to ibendport and smi to qp0, or qpzero if the
> SELinux user space code doesn't allow numbers in access vector identifiers.

Do you know why you'd want to access control qp0 but leave qp1 open?

Still seems kinda strange.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC PATCH v2 00/13] SELinux support for Infiniband RDMA

[Jason Gunthorpe]

On Mon, Apr 11, 2016 at 08:38:50PM +, Daniel Jurgens wrote:

> > This seems superficially similar to netlabel, which I guess targets a
> > certain niche, but I'm really wondering with all the other container
> > patches if this was supposed to be done with namespaces...
> 
> I can't speak to the goals of the other container patches.
> 
> Netlabel can't label kernel bypassed packets.  It can be used for IPoIB
> though.

I guess I'm surprised the first pass at this wasn't to ride on
netlabel at least for all the parts that use IPoIB for addressing (eg
typical rdmacm)

> >> An Infiniband device (ibdev) is labeled by name and port number.  There is 
> >> a
> >> single access vector for ibdevs as well, called "smi".
> > 
> > This is called an End Port (SMI is something else in the IB
> > spec). Please use the standard terminology.
> I see your point on the end port, I'll address this is the next series
> by updating the commit messages and replacing ibdev with ibendport.
> 
> I don't understand where you think I've gone wrong on SMI.

Well, this makes no sense:
 There is a single access vector for ibdevs as well, called "smi".

SMI is not umad. SMI should only refer to the SMA access channel on a
specific node, and I have no idea why someone would want to restrict
local SMA access independently of generic umad qp0 access. Just call
it QP0 or QP1 or umad.

SMI is an obscure internal term that should not be user facing.

Jason
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.