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

From: Alexei Starovoitov <hidden>
Date: 2021-05-12 23:10:23
Also in: bpf

On Tue, May 11, 2021 at 12:44:46AM -0500, YiFei Zhu wrote:
On Mon, May 10, 2021 at 8:58 PM Alexei Starovoitov
[off-list ref] wrote:
quoted
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.
quoted
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.
NULL to mean current->group_leader is too specific and not extensible.
I'd rather add another bpf_get_current_task_btf-like helper that
returns parent or group_leader depending on flags.
For now I wouldn't even do that. As you said hashmap with key=pid will
work fine. task_local_storage is a performance optimization.
I'd focus on landing the key bits before optimizing.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help