On 09/14/16 at 09:23am, Micka?l Sala?n wrote:
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9aa01d9d3d80..36c3e482239c 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context */
> ARG_ANYTHING, /* any (initialized) argument is ok */
> +
> + ARG_PTR_TO_STRUCT_FILE, /* pointer to struct file */
This should go into patch 7 I guess?
> +void __init landlock_add_hooks(void)
> +{
> + pr_info("landlock: Becoming ready for sandboxing\n");
> + security_add_hooks(landlock_hooks, ARRAY_SIZE(landlock_hooks));
> +}
Can we add the hooks when we load the first BPF program for a hook? That
would also allow to not make this conditional on a new config option
which all all distros have to enable anyway.
I would really like to see this patch split into the LSM part which
allows running BPF progs at LSM and your specific sandboxing use case
which requires the new BPF helpers, new reg type, etc.
On 19/10/2016 17:19, Thomas Graf wrote:
> On 09/14/16 at 09:23am, Micka?l Sala?n wrote:
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 9aa01d9d3d80..36c3e482239c 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>>
>> ARG_PTR_TO_CTX, /* pointer to context */
>> ARG_ANYTHING, /* any (initialized) argument is ok */
>> +
>> + ARG_PTR_TO_STRUCT_FILE, /* pointer to struct file */
>
> This should go into patch 7 I guess?
Right, the ARG_PTR_* are only used by BPF helpers.
>
>> +void __init landlock_add_hooks(void)
>> +{
>> + pr_info("landlock: Becoming ready for sandboxing\n");
>> + security_add_hooks(landlock_hooks, ARRAY_SIZE(landlock_hooks));
>> +}
>
> Can we add the hooks when we load the first BPF program for a hook? That
> would also allow to not make this conditional on a new config option
> which all all distros have to enable anyway.
We could either add hook by hook or all hooks at once when loading a BPF
program for which its subtype match the hook type, but I'm not sure it
is worth it.
I'd like to enable this LSM by default but we should be able to disable
it if needed, like most kernel features.
>
> I would really like to see this patch split into the LSM part which
> allows running BPF progs at LSM and your specific sandboxing use case
> which requires the new BPF helpers, new reg type, etc.
>
I'll try to split it as much as possible.