Thread (27 messages) 27 messages, 5 authors, 2021-05-20

Re: [RFC PATCH bpf-next seccomp 12/12] seccomp-ebpf: support task storage from BPF-LSM, defaulting to group leader

flat view

From: YiFei Zhu <hidden>
Date: 2021-05-11 05:45:01
Also in: bpf

On Mon, May 10, 2021 at 8:58 PM Alexei Starovoitov
[off-list ref] wrote:
On Mon, May 10, 2021 at 12:22:49PM -0500, YiFei Zhu wrote:
quoted
+
+BPF_CALL_4(bpf_task_storage_get_default_leader, struct bpf_map *, map,
+        struct task_struct *, task, void *, value, u64, flags)
+{
+     if (!task)
+             task = current->group_leader;
Did you actually need it to be group_leader or current is enough?
If so loading BTF is not necessary.
I think if task_storage were to be used to apply a policy onto a set
of tasks, there are probably more use cases to perform the state
transitions across an entire process than state transitions across a
single thread. Though, since seccomp only applies to the process tree
a lot of use cases of a per-process storage would be covered by a
global datasec too.
You could have exposed it bpf_get_current_task_btf() and passed its
return value into bpf_task_storage_get.

On the other side loading BTF can be relaxed to unpriv,
but doing current->group_leader deref will make it priv only anyway.
Yeah, that deref is what I was concerned about. It seems that if I
expose BTF structs to a prog type it gains the ability to deref it,
and I definitely don't want unpriv reading task_structs. Though yeah
we could potentially change the verifier to prohibit PTR_TO_BTF_ID
deref and any pointer arithmetic on it...

How about, we expose bpf_get_current_task_btf to unpriv, prohibit
unpriv deref and pointer arithmetic, and have NULL be
current->group_leader? This way, unpriv has access to both per-thread
and per-process.

YiFei Zhu
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help