linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Ignatov <rdna@fb.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Network Development" <netdev@vger.kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Roman Gushchin" <guro@fb.com>,
	"Kernel Team" <Kernel-team@fb.com>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Alexey Dobriyan" <adobriyan@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"Jann Horn" <jannh@google.com>,
	"Mickaël Salaün" <mic@digikod.net>
Subject: Re: [PATCH v3 bpf-next 02/21] bpf: Sysctl hook
Date: Tue, 9 Apr 2019 20:16:45 +0000	[thread overview]
Message-ID: <20190409201641.GA43779@rdna-mbp> (raw)
In-Reply-To: <CAGXu5j+hW4NPihH+LmvCRxpNdHJDh=KD=k2FtFx51Ay8=vSdgA@mail.gmail.com>

Kees Cook <keescook@chromium.org> [Tue, 2019-04-09 09:54 -0700]:
> On Fri, Apr 5, 2019 at 12:36 PM Andrey Ignatov <rdna@fb.com> wrote:
> > Containerized applications may run as root and it may create problems
> > for whole host. Specifically such applications may change a sysctl and
> > affect applications in other containers.
> >
> > Furthermore in existing infrastructure it may not be possible to just
> > completely disable writing to sysctl, instead such a process should be
> > gradual with ability to log what sysctl are being changed by a
> > container, investigate, limit the set of writable sysctl to currently
> > used ones (so that new ones can not be changed) and eventually reduce
> > this set to zero.
> 
> Actual-root-in-a-container is pretty powerful. What about module
> loading, or /dev files? Instead of sysctl-specific hooks, what about
> VFS hooks, which would be able to cover all file-based APIs. This is
> what, for example, Landlock was working on doing (also with eBPF).

This sysctl hook doesn't try to solve all possible problems that
root-in-a-container may impose, but rather focuses on one specific
problem.

Generic BPF hooks in VFS can be a good idea and in fact there was a try
to add BPF hook for file_open [1], but apparently it needs more work.

Flexibility of generic hooks has its disadvantages though when it comes
to making what this sysctl-focused hook does. E.g. with sysctl hook
administrator shouldn't care about sys_open, sys_read, sys_write
separately if they want to implement policies (or just tracing) based on
sysctl name / value for cgroup, but can have just one BPF program
instead that has all necessary context to make decisions.

Also accesses to sysctl is usually just a very small part of all calls
to sys_open/sys_read/sys_write on a system, outside of fast-path (e.g.
nobody should care if write to sysctl is a bit slower), and calling BPF
hook for every sys_open/sys_read/sys_write when administrator wants to
limit just sysctl changes can be too expensive.

Furthermore sysctl focused hook allows to tailor its API to sysctl needs
and avoid exposing APIs that make sense only for sysctl to all
file-based accesses and vise versa.

[1] https://lwn.net/Articles/767615/

-- 
Andrey Ignatov

  reply	other threads:[~2019-04-09 20:17 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-05 19:35 [PATCH v3 bpf-next 00/21] bpf: Sysctl hook Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 01/21] bpf: Add base proto function for cgroup-bpf programs Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 02/21] bpf: Sysctl hook Andrey Ignatov
2019-04-09 16:54   ` Kees Cook
2019-04-09 20:16     ` Andrey Ignatov [this message]
2019-04-05 19:35 ` [PATCH v3 bpf-next 03/21] bpf: Introduce bpf_sysctl_get_name helper Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 04/21] bpf: Introduce bpf_sysctl_get_current_value helper Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 05/21] bpf: Introduce bpf_sysctl_{get,set}_new_value helpers Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 06/21] bpf: Add file_pos field to bpf_sysctl ctx Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 07/21] bpf: Sync bpf.h to tools/ Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 08/21] libbpf: Support sysctl hook Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 09/21] selftests/bpf: Test sysctl section name Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 10/21] selftests/bpf: Test BPF_CGROUP_SYSCTL Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 11/21] selftests/bpf: Test bpf_sysctl_get_name helper Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 12/21] selftests/bpf: Test sysctl_get_current_value helper Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 13/21] selftests/bpf: Test bpf_sysctl_{get,set}_new_value helpers Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 14/21] selftests/bpf: Test file_pos field in bpf_sysctl ctx Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 15/21] bpf: Introduce ARG_PTR_TO_{INT,LONG} arg types Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 16/21] bpf: Introduce bpf_strtol and bpf_strtoul helpers Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 17/21] bpf: Sync bpf.h to tools/ Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 18/21] selftests/bpf: Add sysctl and strtoX helpers to bpf_helpers.h Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 19/21] selftests/bpf: Test ARG_PTR_TO_LONG arg type Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 20/21] selftests/bpf: Test bpf_strtol and bpf_strtoul helpers Andrey Ignatov
2019-04-05 19:35 ` [PATCH v3 bpf-next 21/21] selftests/bpf: C based test for sysctl and strtoX Andrey Ignatov
2019-04-06 16:43 ` [PATCH v3 bpf-next 00/21] bpf: Sysctl hook Kees Cook
2019-04-06 17:02   ` Alexei Starovoitov
2019-04-09 16:50     ` Kees Cook
2019-04-09 23:17       ` Andrey Ignatov
2019-04-09 20:41 ` Jann Horn
2019-04-09 23:04   ` Andrey Ignatov
2019-04-09 23:22     ` Jann Horn
2019-04-09 23:34       ` Alexei Starovoitov
2019-04-12 21:27 ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190409201641.GA43779@rdna-mbp \
    --to=rdna@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=adobriyan@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=guro@fb.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mic@digikod.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).