Hi Kees, On Thu, Jun 1, 2017 at 9:10 PM, Kees Cook <keescook@xxxxxxxxxx> wrote: > On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni <tixxdz@xxxxxxxxx> wrote: ... > >> BTW Kees, also in next version I won't remove the >> capable(CAP_NET_ADMIN) check from [1] >> even if there is the new request_module_cap(), I would like it to be >> in a different patches, this way we go incremental >> and maybe it is better to merge what we have now ? and follow up >> later, and of course if other maintainers agree too! > > Yes, incremental. I would suggest first creating the API changes to > move a basic require_cap test into the LSM (which would drop the > open-coded capable() checks in the net code), and then add the > autoload logic in the following patches. That way the "infrastructure" > changes happen separately and do not change any behaviors, but moves > the caps test down where its wanted in the LSM, before then augmenting > the logic. > >> I just need a bit of free time to check again everything and will send >> a v5 with all requested changes. > > Great, thank you! > So sorry was busy these last months, I picked it again, will send v5 after the merge window. Kees I am looking on a way to integrate a test for it, we should use something like the example here [1] or maybe something else ? and which module to use ? I still did not sort this out, if anyone has some suggestions, thank you in advance! [1] http://openwall.com/lists/kernel-hardening/2017/05/22/7 -- tixxdz -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
