Quoting Will Drewry ([email protected]):
> [This patch depends on [email protected]'s no_new_privs patch:
> https://lkml.org/lkml/2012/1/12/446
> ]
>
> This patch adds support for seccomp mode 2. This mode enables dynamic
> enforcement of system call filtering policy in the kernel as specified
> by a userland task. The policy is expressed in terms of a Berkeley
> Packet Filter program, as is used for userland-exposed socket filtering.
> Instead of network data, the BPF program is evaluated over struct
> seccomp_filter_data at the time of the system call.
>
> A filter program may be installed by a userland task by calling
> prctl(PR_ATTACH_SECCOMP_FILTER, &fprog);
> where fprog is of type struct sock_fprog.
>
> If the first filter program allows subsequent prctl(2) calls, then
> additional filter programs may be attached. All attached programs
> must be evaluated before a system call will be allowed to proceed.
>
> To avoid CONFIG_COMPAT related landmines, once a filter program is
> installed using specific is_compat_task() value, it is not allowed to
> make system calls using the alternate entry point.
>
> Filter programs will be inherited across fork/clone and execve, however
> the installation of filters must be preceded by setting 'no_new_privs'
> to ensure that unprivileged tasks cannot attach filters that affect
> privileged tasks (e.g., setuid binary). Tasks with CAP_SYS_ADMIN
> in their namespace may install inheritable filters without setting
> the no_new_privs bit.
>
> There are a number of benefits to this approach. A few of which are
> as follows:
> - BPF has been exposed to userland for a long time.
> - Userland already knows its ABI: system call numbers and desired
> arguments
> - No time-of-check-time-of-use vulnerable data accesses are possible.
> - system call arguments are loaded on demand only to minimize copying
> required for system call number-only policy decisions.
>
> This patch includes its own BPF evaluator, but relies on the
> net/core/filter.c BPF checking code. It is possible to share
> evaluators, but the performance sensitive nature of the network
> filtering path makes it an iterative optimization which (I think :) can
> be tackled separately via separate patchsets. (And at some point sharing
> BPF JIT code!)
>
> v6: - fix memory leak on attach compat check failure
> - require no_new_privs || CAP_SYS_ADMIN prior to filter
> installation. ([email protected])
> - s/seccomp_struct_/seccomp_/ for macros/functions
> ([email protected])
> - cleaned up Kconfig ([email protected])
> - on block, note if the call was compat (so the # means something)
> v5: - uses syscall_get_arguments
> ([email protected],[email protected], [email protected])
> - uses union-based arg storage with hi/lo struct to
> handle endianness. Compromises between the two alternate
> proposals to minimize extra arg shuffling and account for
> endianness assuming userspace uses offsetof().
> ([email protected], [email protected])
> - update Kconfig description
> - add include/seccomp_filter.h and add its installation
> - (naive) on-demand syscall argument loading
> - drop seccomp_t ([email protected])
> v4: - adjusted prctl to make room for PR_[SG]ET_NO_NEW_PRIVS
> - now uses current->no_new_privs
> ([email protected],[email protected])
> - assign names to seccomp modes ([email protected])
> - fix style issues ([email protected])
> - reworded Kconfig entry ([email protected])
> v3: - macros to inline ([email protected])
> - init_task behavior fixed ([email protected])
> - drop creator entry and extra NULL check ([email protected])
> - alloc returns -EINVAL on bad sizing ([email protected])
> - adds tentative use of "always_unprivileged" as per
> [email protected] and [email protected]
> v2: - (patch 2 only)
>
> Signed-off-by: Will Drewry <[email protected]>
Hi Will,
as far as I can tell based on changelog I suspect you could have
kept my Acked-by (from v3?). However, I'll wait until your next
submission (as I see there were a few change requests), and do a
final complete new review of that.
Thanks for continuing to push on this.
-serge
On Thu, Feb 2, 2012 at 7:32 AM, Serge E. Hallyn
<[email protected]> wrote:
> Quoting Will Drewry ([email protected]):
>> [This patch depends on [email protected]'s no_new_privs patch:
>> ?https://lkml.org/lkml/2012/1/12/446
>> ]
>>
>> This patch adds support for seccomp mode 2. ?This mode enables dynamic
>> enforcement of system call filtering policy in the kernel as specified
>> by a userland task. ?The policy is expressed in terms of a Berkeley
>> Packet Filter program, as is used for userland-exposed socket filtering.
>> Instead of network data, the BPF program is evaluated over struct
>> seccomp_filter_data at the time of the system call.
>>
>> A filter program may be installed by a userland task by calling
>> ? prctl(PR_ATTACH_SECCOMP_FILTER, &fprog);
>> where fprog is of type struct sock_fprog.
>>
>> If the first filter program allows subsequent prctl(2) calls, then
>> additional filter programs may be attached. ?All attached programs
>> must be evaluated before a system call will be allowed to proceed.
>>
>> To avoid CONFIG_COMPAT related landmines, once a filter program is
>> installed using specific is_compat_task() value, it is not allowed to
>> make system calls using the alternate entry point.
>>
>> Filter programs will be inherited across fork/clone and execve, however
>> the installation of filters must be preceded by setting 'no_new_privs'
>> to ensure that unprivileged tasks cannot attach filters that affect
>> privileged tasks (e.g., setuid binary). ?Tasks with CAP_SYS_ADMIN
>> in their namespace may install inheritable filters without setting
>> the no_new_privs bit.
>>
>> There are a number of benefits to this approach. A few of which are
>> as follows:
>> - BPF has been exposed to userland for a long time.
>> - Userland already knows its ABI: system call numbers and desired
>> ? arguments
>> - No time-of-check-time-of-use vulnerable data accesses are possible.
>> - system call arguments are loaded on demand only to minimize copying
>> ? required for system call number-only policy decisions.
>>
>> This patch includes its own BPF evaluator, but relies on the
>> net/core/filter.c BPF checking code. ?It is possible to share
>> evaluators, but the performance sensitive nature of the network
>> filtering path makes it an iterative optimization which (I think :) can
>> be tackled separately via separate patchsets. (And at some point sharing
>> BPF JIT code!)
>>
>> ?v6: - fix memory leak on attach compat check failure
>> ? ? ?- require no_new_privs || CAP_SYS_ADMIN prior to filter
>> ? ? ? ?installation. ([email protected])
>> ? ? ?- s/seccomp_struct_/seccomp_/ for macros/functions
>> ? ? ? ?([email protected])
>> ? ? ?- cleaned up Kconfig ([email protected])
>> ? ? ?- on block, note if the call was compat (so the # means something)
>> ?v5: - uses syscall_get_arguments
>> ? ? ? ?([email protected],[email protected], [email protected])
>> ? ? ?- uses union-based arg storage with hi/lo struct to
>> ? ? ? ?handle endianness. ?Compromises between the two alternate
>> ? ? ? ?proposals to minimize extra arg shuffling and account for
>> ? ? ? ?endianness assuming userspace uses offsetof().
>> ? ? ? ?([email protected], [email protected])
>> ? ? ?- update Kconfig description
>> ? ? ?- add include/seccomp_filter.h and add its installation
>> ? ? ?- (naive) on-demand syscall argument loading
>> ? ? ?- drop seccomp_t ([email protected])
>> ?v4: - adjusted prctl to make room for PR_[SG]ET_NO_NEW_PRIVS
>> ? ? ?- now uses current->no_new_privs
>> ? ? ? ? ?([email protected],[email protected])
>> ? ? ?- assign names to seccomp modes ([email protected])
>> ? ? ?- fix style issues ([email protected])
>> ? ? ?- reworded Kconfig entry ([email protected])
>> ?v3: - macros to inline ([email protected])
>> ? ? ?- init_task behavior fixed ([email protected])
>> ? ? ?- drop creator entry and extra NULL check ([email protected])
>> ? ? ?- alloc returns -EINVAL on bad sizing ([email protected])
>> ? ? ?- adds tentative use of "always_unprivileged" as per
>> ? ? ? [email protected] and [email protected]
>> ?v2: - (patch 2 only)
>>
>> Signed-off-by: Will Drewry <[email protected]>
>
> Hi Will,
>
> as far as I can tell based on changelog I suspect you could have
> kept my Acked-by (from v3?). ?However, I'll wait until your next
> submission (as I see there were a few change requests), and do a
> final complete new review of that.
Thanks, Serge! I just failed at the proper protocol and didn't mean
to not include your Acked-by. However, I am changing a fair amount
of the internals this time around, so I'll be happy to have another
full review.
> Thanks for continuing to push on this.
Definitely! I've been traveling this week, so it's been a bit slow
going, but I hope to have the next rev up early next week if not
sooner.
Cheers!
will