Feature proposal - Attaching probes to cgroups

Feature proposal - Attaching probes to cgroups

[Gilad Reti]

Hello everyone,

Are there any plans on extending the cgroup program types to include
more probe types (or possibly allow restricting any probe type to a
specific cgroup)?

For a use case example, this will allow attaching programs to the
"docker" cgroup and thus tracing events from containers only (or even
enforcing eBPF LSM on docker containers only).

Another use case that I can think of is shared cloud infrastructure -
attaching eBPF probes in those environments is risky from the security
point of view since one cannot restrict tracing to its own resources
only (containers, etc.). Allowing restricting bpf probes to a cgroup
may allow creating a cgroup for each user's resources and allowing it
to attach programs to its cgroup only.

Thanks,
Gilad Reti

Re: Feature proposal - Attaching probes to cgroups

[Daniel Xu]

On Tue, Dec 8, 2020, at 2:40 AM, Gilad Reti wrote:
> Hello everyone,
> 
> Are there any plans on extending the cgroup program types to include
> more probe types (or possibly allow restricting any probe type to a
> specific cgroup)?
> 
> For a use case example, this will allow attaching programs to the
> "docker" cgroup and thus tracing events from containers only (or even
> enforcing eBPF LSM on docker containers only).

Based on my understanding, this may not be possible. For example, the
kernel may lose information about cgroups on deferred work. When the
work is later executed, the cgroup may lose information on work it technically
initiated.

Daniel

Re: Feature proposal - Attaching probes to cgroups

[Alexei Starovoitov]

On Tue, Dec 8, 2020 at 12:38 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> On Tue, Dec 8, 2020, at 2:40 AM, Gilad Reti wrote:
> > Hello everyone,
> >
> > Are there any plans on extending the cgroup program types to include
> > more probe types (or possibly allow restricting any probe type to a
> > specific cgroup)?

This kind of feature was requested earlier.
The rough idea was to add a program hook in the cgroup attach path.
So that prog can decide which progs to which cgroups are ok.
It's a bit tautological and not everyone was happy with the idea.
No patches were produced either.
Other ideas of extending existing default/override/multi logic were rejected
as not flexible and not generic enough.

> > For a use case example, this will allow attaching programs to the
> > "docker" cgroup and thus tracing events from containers only (or even
> > enforcing eBPF LSM on docker containers only).
>
> Based on my understanding, this may not be possible. For example, the
> kernel may lose information about cgroups on deferred work. When the
> work is later executed, the cgroup may lose information on work it technically
> initiated.
>
> Daniel