On Tue, Apr 9, 2019 at 10:26 PM Andrey Ignatov [off-list ref] wrote:

The patch set introduces new BPF hook for sysctl.

It adds new program type BPF_PROG_TYPE_CGROUP_SYSCTL and attach type
BPF_CGROUP_SYSCTL.

BPF_CGROUP_SYSCTL hook is placed before calling to sysctl's proc_handler so
that accesses (read/write) to sysctl can be controlled for specific cgroup
and either allowed or denied, or traced.

Don't look at the credentials of "current" in a read or write handler.
Consider what happens if, for example, someone inside a cgroup opens a
sysctl file and passes the file descriptor to another process outside
the cgroup over a unix domain socket, and that other process then
writes to it. Either do your access check on open, or use the
credentials that were saved during open() in the read/write handler.

The hook has access to sysctl name, current sysctl value and (on write
only) to new sysctl value via corresponding helpers. New sysctl value can
be overridden by program. Both name and values (current/new) are
represented as strings same way they're visible in /proc/sys/. It is up to
program to parse these strings.

But even if a filter is installed that prevents all access to a
sysctl, you can still read it by installing your own filter that, when
a read is attempted the next time, dumps the value into a map or
something like that, right?

To help with parsing the most common kind of sysctl value, vector of
integers, two new helpers are provided: bpf_strtol and bpf_strtoul with
semantic similar to user space strtol(3) and strtoul(3).

The hook also provides bpf_sysctl context with two fields:
* @write indicates whether sysctl is being read (= 0) or written (= 1);
* @file_pos is sysctl file position to read from or write to, can be
  overridden.

The hook allows to make better isolation for containerized applications
that are run as root so that one container can't change a sysctl and affect
all other containers on a host, make changes to allowed sysctl in a safer
way and simplify sysctl tracing for cgroups.

Why can't you use a user namespace and isolate things properly that
way? That would be much cleaner, wouldn't it?