On Wed, Jun 27, 2018 at 07:38:33AM -0500, Daniel Jurgens wrote: > > > On 6/26/2018 5:43 PM, Jason Gunthorpe wrote: > > On Tue, Jun 26, 2018 at 05:33:10PM -0500, Daniel Jurgens wrote: > > > >>> Overall, I don't understand why ipoib is even *doing* selinux checks > >>> at all. Surely that is the bug, isn't it? > >>> > >>> ipoib is *kernel* code, other that 'create child' it is not triggered > >>> by the user, and certianly should not inherit the security context of > >>> the module loader during startup. > >> The process has the security context, not the code. > > I think it is wrong to enforce pkey checks during things like > > module_init(), makes no sense. > And how is the verbs code supposed to know the QP is being modified > during module_init and skip checking then? This is a policy "bug", > not an enforcement bug. Well, you are not supposed to have enforcement for kernel calls at all, just uverbs ones, and kernel ones that know they have a security context to give. So, this means in ib_security_modify_qp, it should do nothing if udata is NULL. > > If the user has permission to load a module then there should not be > > additional permission needed beyond that for the module to initialize > > properly. > Why? Because a user has a permission to load a module now they > should automatically have permission to use IB resources? There are > many types of modules that that user could load that wouldn't allow > them access to the outside world. Policy is granular, it's a > feature. Yes, because if my module_init runs the init task in a system work queue (as an example) it should not have a different security behavior. Once you are in the kernel you are trusted and expected to call security calls when necessary. It is not appropriate for ipoib to do security calls during it's module init. Jason -- 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
