On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni <tixxdz@xxxxxxxxx> wrote:
> module_require_cap = 0;
>
> if (autoload == MODULES_AUTOLOAD_DISABLED)
> return -EPERM;
>
> if (autoload == MODULES_AUTOLOAD_PRIVILEGED || require_cap > 0) {
> if (prefix != NULL && *prefix != '\0')
> /*
> * Allow non-CAP_SYS_MODULE caps when
> * using a distinct prefix.
> */
> module_require_cap = require_cap;
> else
> /*
> * Otherwise always require CAP_SYS_MODULE if no
> * valid prefix. Callers that do not provide a valid prefix
> * should not provide a require_cap > 0
> */
> module_require_cap = CAP_SYS_MODULE;
> }
>
> /* If autoload allowed and 'module_require_cap' was *never* set, allow */
> if (module_require_cap == 0 && autoload == MODULES_AUTOLOAD_ALLOWED)
> return 0;
>
> return capable(module_require_cap) ? 0 : -EPERM;
>
> Maybe you will agree :-) ?
Yes! Looks good. I was accidentally still thinking about the caps
checks being in the net code, but obviously, that wouldn't be the case
anymore. Thanks for the catch. :)
> 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!
-Kees
--
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
