4 ms·
On the surface this seems similar to seccomp https://www.man7.org/linux/man-pages/man2/seccomp.2.html https://www.man7.org/linux/man-pages/man2/seccomp.2.html
by rdtsc 3y ago
On the surface this seems similar to seccomp https://www.man7.org/linux/man-pages/man2/seccomp.2.html https://www.man7.org/linux/man-pages/man2/seccomp.2.html
- viraptor 3y agoIt's way simpler. Seccomp is a pita to keep current and complete. Landlock is higher level with concepts of filesystem locations rather than basic low level ops.
- rdtsc 3y agoThanks for explaining. I had tried using seccomp in some previous incarnation, before it allowed passing in ebpf filters, and it was just too restrictive so had to abandon that effort.
- IshKebab 3y agoSeccomp can't really do this... at least not without serious hacks. I've tried. There are at least two big issues: * Seccomp intercepts syscalls, and paths are passed to syscalls as pointers. So your code that has to decide "is this syscall allowed?" doesn't get the path, it gets a pointer to a path in another process's address space. That means you have to then pretty much debug that process to find the string. However IIRC there are potential races between when you read the string and when the kernel does. * Symlinks mean you can't just do a lexical check on the path. Hell you can't even lexically normalise it (remove all `../foo`) because symlinks are crazy. For something like creating files/directories IIRC you have to walk up the path starting from root and read every directory from disk. Like open `/foo`, ok? now open `/foo/bar`, now `/foo/bar/baz`... Total nightmare. Landlock is much saner for filesystem sandboxing.