On 5/16/2016 3:15 PM, Doug Ledford wrote:
> On 05/15/2016 02:00 AM, Leon Romanovsky wrote:
>> On Sat, May 14, 2016 at 09:09:54AM -0400, Doug Ledford wrote:
>>> On 05/14/2016 12:33 AM, Leon Romanovsky wrote:
>>>> On Fri, May 13, 2016 at 12:31:55PM -0400, Doug Ledford wrote:
>>
>> What is wrong with SELinux patches?
>
> They need time for people to think about them. You call them the
> SELinux patches, but that is somewhat misleading. When I think of
> SELinux, I think of things like limited context server applications
> ("Can httpd read home directories?", "Can dovecot write to home
> direcories? Can dovecot listen on port 993? 995?", etc.) It's very
The patches are intended to allow exactly that. Extend the SELinux
policy language to support controlling access to Infiniband partitions.
> general purpose and has a lot of policy that goes with it. From what I
> read, these patches are different. They are mainly used to enforce the
> subnet manager's P_Key policy. There isn't anything else they do. From
They don't have anything to do with the subnet managers PKey policy.
They enforce SELinux policy to restrict access to partitions.
> that standpoint, they look like the user space half of the namespace
> equation. But they're devoid of any of the other policy decisions that
> SELinux often makes. I haven't read them closes enough to see if they
> could be easily extended to implement any of these other types of policy
> or not, but that's certainly an issue. If you are going to go monkeying
> around in the SELinux subsystem (and 7 of the 12 patches do), then
> making sure we do things in a manner that is not going to paint us into
> a corner seems appropriate. I haven't had the time to do that level of
> looking at these patches.
Changes to the SELinux subsystem are required to support the changes to
the policy language to label Infiniband pkeys and devices and to provide
an access control query interface.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
