On 6/26/2018 3:47 PM, Jason Gunthorpe wrote:
> On Tue, Jun 26, 2018 at 03:38:25PM -0500, Daniel Jurgens wrote:
>
>> type=AVC msg=audit(1529969961.770:111): avc: denied { access } for
>> pid=932 comm="systemd-network" pkey=0xffff subnet_prefix=0:0:0:80fe::
>> scontext=system_u:system_r:systemd_modules_load_t:s0
>> tcontext=system_u:object_r:unlabeled_t:s0 tclass=infiniband_pkey
>> permissive=0
>>
>> The upstream refpolicy doesn't define systemd_modules_load_t, I
>> think this will require an update to the fedora selinux policy to
>> allow access to unlabeled pkeys for that type. I've added Paul
>> Moore, hopefully he knows how to make that happen.
> But that is for systemd-network, not 'ip link up' ?
>
> I wonder if systemd-network somehow did the module load, and during
> ipoib boot up it got denied - and that caused a bad state inside ipoib
> which crashes a later ip link?
That could be the case. One would have to check the AVC log prior to attempting the ip link command. I don't have a setup to check that right now.
>
> But that still entirely doesn't make sense, how did systemd-network
> trigger a module load, and how did it get a module_load label?
>
> Modules should only be loaded by /lib/systemd/systemd-modules-load ??
>
> Confusing.
Systemd_modules_load_t type tried to do the access that got denied. It would make a lot of sense that
/lib/systemd/systemd-modules-load would run with that type.
> 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.
> Or no?
>
> 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
