[language]

There's some kind of bind here between "putting burden on end-users" and "putting burden on application developers." Either you (a) ship $LSM with some defaults that are necessarily general (so as to avoid breaking applications) and let the user fit filters to their circumstances, or; (b) push for developers to write/maintain filters baked into their applications (ie. using some kernel features like `seccomp` and what-have-you).

[ris]

seccomp and LSMs do different (and complementary) things.

[language]

How so? I understand they're different, but I thought there was some overlap. Don't LSMs work by hooking syscalls anyway?

[AstralStorm]

Seccomp can only disable syscalls. LSMs are more nuanced. Three most important difference is that it is easy to check if seccomp is available and the policy is not kept in or on a file.

[language]

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]

It 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]

Thanks 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.