3 ms·
I was under the impression that seccomp was a bit more flexible (via ptrace() and BPF fanciness) - although I guess you'd need other co-operating processes in u
by language 9y ago
I was under the impression that seccomp was a bit more flexible (via ptrace() and BPF fanciness) - although I guess you'd need other co-operating processes in userspace? I've only played around with it a tiny bit.
Also, both kinds of policy are resident in files. I don't understand your point there.
- ris 9y agoIt is flexible to an extent, but you still can't e.g. deference a pointer to a struct passed as an argument. And that's where much of the interesting detail is for many calls.
- language 9y agoThanks for the clarification, although I recall messing with eBPF and kprobes before - pretty sure you can dereference pointers? editx2: Oh, guess seccomp doesn't use eBPF yet? Suppose that raises a bunch of questions about permissions necessary for specifying programs that might dereference kernel pointers and such by emitting `bpf()` calls.