[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210512095823.99162-1-yunbo.xufeng@linux.alibaba.com>
Date: Wed, 12 May 2021 17:58:22 +0800
From: Xufeng Zhang <yunbo.xufeng@...ux.alibaba.com>
To: kpsingh@...nel.org, ast@...nel.org, daniel@...earbox.net,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org
Cc: revest@...omium.org, jackmanb@...omium.org, yhs@...com,
songliubraving@...com, kafai@...com, john.fastabend@...il.com,
joe@...ium.io, quentin@...valent.com,
Xufeng Zhang <yunbo.xufeng@...ux.alibaba.com>
Subject: [RFC] [PATCH bpf-next 0/1] Implement getting cgroup path bpf helper
In order to protect the running application containers by utilizing
bpf LSM, we need to upload the security rules into bpf maps in container
granularity, however, there is no effective bpf helper to identify the
container, especially for cgroup v1. Generally, the only thing which the
user side can get is container ID, and the cgroup path for this running
container is fixed if we know the container ID, therefore, bpf programs
also need to get the cgroup path for the running task in order to apply
security rules stored in bpf maps.
This patch add a bpf helper - bpf_get_current_cpuset_cgroup_path(), which
return the cpuset cgroup path for the current task, since cgroup_path_ns()
can sleep, this helper is only allowed for sleepable LSM hooks.
Concern:
Since cgroup_path_ns() takes 'cgroup_mutex' and 'css_set_lock' lock,
I'm not sure if there is any dead lock code path in LSM hooks.
Xufeng Zhang (1):
bpf: Add a BPF helper for getting the cgroup path of current task
---
include/uapi/linux/bpf.h | 13 +++++++++++++
kernel/bpf/bpf_lsm.c | 28 ++++++++++++++++++++++++++++
tools/include/uapi/linux/bpf.h | 13 +++++++++++++
3 files changed, 54 insertions(+)
Powered by blists - more mailing lists