Interesting they added new syscalls, instead of handling configuration via /sys like with SELinux and AppArmor. I suppose it must be because of the no privilege principle.
Can sysadmins disable access to Landlock syscalls via seccomp? Not that I can see why they'd want to, just wondering how this is layered.
I suppose the problem might be if the system has been set up at some earlier point in time to whitelist a set of syscalls for a process and, as Landlock is newer, its syscall numbers won't be included. A program that has been updated to use Landlock while a seccomp policy that predates Landlock is applied would presumably be terminated with SIGSYS due to this?
How can a program determine if Landlock is present without just trying the syscalls and seeing if they work?
Other LSMs are slowly switching to syscalls too, and while I in principle like (and have abused) the whole "everything is a file" principle, most security mechanisms really should be done via special-purpose syscalls. Way too many footguns with filesystem-based APIs. Also, you wouldn't be able to use Landlock to restrict filesystem access based on dirfds with a filesystem-based API.
The questions you have about seccomp depend on the rules. Well-written filters would return -ENOSYS in that case, so it would look to the program as though the syscall is unsupported.
You can restrict the landlock syscalls with seccomp.
I also don't think doing so is extraordinarily useful.
If you allow something in landlock, it's still subject to traditional DAC and other restrictions because its a stackable LSM. It can only restrict existing access, not allow new accesses.
Comments
Interesting they added new syscalls, instead of handling configuration via /sys like with SELinux and AppArmor. I suppose it must be because of the no privilege principle.
Can sysadmins disable access to Landlock syscalls via seccomp? Not that I can see why they'd want to, just wondering how this is layered.
I suppose the problem might be if the system has been set up at some earlier point in time to whitelist a set of syscalls for a process and, as Landlock is newer, its syscall numbers won't be included. A program that has been updated to use Landlock while a seccomp policy that predates Landlock is applied would presumably be terminated with SIGSYS due to this?
How can a program determine if Landlock is present without just trying the syscalls and seeing if they work?
Other LSMs are slowly switching to syscalls too, and while I in principle like (and have abused) the whole "everything is a file" principle, most security mechanisms really should be done via special-purpose syscalls. Way too many footguns with filesystem-based APIs. Also, you wouldn't be able to use Landlock to restrict filesystem access based on dirfds with a filesystem-based API.
The questions you have about seccomp depend on the rules. Well-written filters would return -ENOSYS in that case, so it would look to the program as though the syscall is unsupported.
You can restrict the landlock syscalls with seccomp.
I also don't think doing so is extraordinarily useful.
If you allow something in landlock, it's still subject to traditional DAC and other restrictions because its a stackable LSM. It can only restrict existing access, not allow new accesses.