Hacker News Reader

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

View on HN

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.

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.

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.

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.

Reply on news.ycombinator.com