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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/8/2016 11:20 AM, Jason Gunthorpe wrote:
> On Thu, Sep 08, 2016 at 02:12:48PM +0000, Daniel Jurgens wrote:
>
>> It would have to include the port, but idea of using a device name
>> for this is pretty ugly.  <subnet_prefix,pkey> makes it very easy to
>> write a policy that can be deployed widely.  <device,port,pkey/vlan>
>> 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
>
Net has variety of means of enforcement, one of which is controlling access to ports <tcp/udp,port number>, which is the most like what I'm doing here.  They also have other enforcement options that can't work for RDMA because it bypasses the kernel.

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 with this aside from it being where the policy is stored before being loaded.  What is this dynamic injector you are talking about?

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.

This hypothetical policy could be deployed on both:

    pkeycon 0xfe80:: 0xFFFF  gen_context(system_u:object_r:default_pkey_t);

    allow sysadm_t default_pkey_t access;

If we use device name you'd need to write separate policy for each node.

    pkeyvlancon mlx4_0 1 0xFFFF gen_context(system_u:object_r:default_pkey_t);

or

    pkeyvlancon mlx5_0 1 0xFFFF gen_context(system_u:object_r:default_pkey_t);




_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux