Date:   Wed, 14 Feb 2018 01:47:10 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     Sargun Dhillon <sargun@...gun.me>
Cc:     netdev@...r.kernel.org, wad@...omium.org, keescook@...omium.org,
        daniel@...earbox.net, containers@...ts.linux-foundation.org,
        ast@...nel.org, luto@...capital.net
Subject: Re: [PATCH net-next 0/3] eBPF Seccomp filters

seccomp-bpf does not use cBPF but a subset of it. The reason is that it
is meant to reduce the attack surface of the kernel. By limiting the
number of instructions allowed by seccomp-bpf, it really reduce the
possibilities for an attacker to use seccomp-bpf as an entry point to
attack the kernel. Moreover, this subset of cBPF is just fine to filter
simple things as syscall numbers and arguments. Additional return codes
may be added to extend seccomp features.

FYI, I'm tweaking a new version of Landlock, which is not an extension
of seccomp-bpf (as it was at first) but a standalone LSM leveraging eBPF
to create security sandboxes (what seccomp-bpf does not do). I'll send
this version soon but you can get a sneak peek here (the documentation
will come with the final version):
https://github.com/landlock-lsm/linux/commit/6c9131a5ccdf7aa599999b23f3a9ae2b73008f41
(please, do not comment this code now)

I think the current seccomp-bpf bytecode is excellent for what it is
meant to do. Landlock leverage eBPF to tackle a more complex problem
(e.g. control access to files, and much more). It is not a seccomp
replacement but a complementary layer of security.

About the verbosity of seccomp filters, you may want to try other ways
to write policies (e.g. https://github.com/google/kafel/ or
https://android.googlesource.com/platform/external/minijail/+/master/tools/generate_seccomp_policy.py
or https://github.com/servo/gaol/blob/master/platform/linux/seccomp.rs).

Regards,
 Mickaël

On 13/02/2018 16:42, Sargun Dhillon wrote:
> This patchset enables seccomp filters to be written in eBPF. Although,
> this patchset doesn't introduce much of the functionality enabled by
> eBPF, it lays the ground work for it.
> 
> It also introduces the capability to dump eBPF filters via the PTRACE
> API in order to make it so that CHECKPOINT_RESTORE will be satisifed.
> In the attached samples, there's an example of this. One can then use
> BPF_OBJ_GET_INFO_BY_FD in order to get the actual code of the program,
> and use that at reload time.
> 
> The primary reason for not adding maps support in this patchset is
> to avoid introducing new complexities around PR_SET_NO_NEW_PRIVS.
> If we have a map that the BPF program can read, it can potentially
> "change" privileges after running. It seems like doing writes only
> is safe, because it can be pure, and side effect free, and therefore
> not negatively effect PR_SET_NO_NEW_PRIVS. Nonetheless, if we come
> to an agreement, this can be in a follow-up patchset.
> 
> 
> Sargun Dhillon (3):
>   bpf, seccomp: Add eBPF filter capabilities
>   seccomp, ptrace: Add a mechanism to retrieve attached eBPF seccomp
>     filters
>   bpf: Add eBPF seccomp sample programs
> 
>  arch/Kconfig                 |   7 ++
>  include/linux/bpf_types.h    |   3 +
>  include/linux/seccomp.h      |  12 +++
>  include/uapi/linux/bpf.h     |   2 +
>  include/uapi/linux/ptrace.h  |   5 +-
>  include/uapi/linux/seccomp.h |  15 ++--
>  kernel/bpf/syscall.c         |   1 +
>  kernel/ptrace.c              |   3 +
>  kernel/seccomp.c             | 185 ++++++++++++++++++++++++++++++++++++++-----
>  samples/bpf/Makefile         |   9 +++
>  samples/bpf/bpf_load.c       |   9 ++-
>  samples/bpf/seccomp1_kern.c  |  17 ++++
>  samples/bpf/seccomp1_user.c  |  34 ++++++++
>  samples/bpf/seccomp2_kern.c  |  24 ++++++
>  samples/bpf/seccomp2_user.c  |  66 +++++++++++++++
>  15 files changed, 362 insertions(+), 30 deletions(-)
>  create mode 100644 samples/bpf/seccomp1_kern.c
>  create mode 100644 samples/bpf/seccomp1_user.c
>  create mode 100644 samples/bpf/seccomp2_kern.c
>  create mode 100644 samples/bpf/seccomp2_user.c
> 



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists