Comment by roer
If you're trying to deny internet access to a program, beware that landlock only restricts tcp sockets. Programs are free to setup udp or just raw sockets.
If you're trying to deny internet access to a program, beware that landlock only restricts tcp sockets. Programs are free to setup udp or just raw sockets.
It's just incomplete and very early days for landlock.
Landlock requires you to commit upfront to what is "deny-default"ed but they only added a control for TCP socket bind and nothing else. So you can "default-deny" tcp bind but all the other socket paths in the kernel are not guarded by landlock. It tries really hard to have the commit of features be an integral part of the landlock API so that you can have an application able to run on multiple kernel versions that support different parts of the landlock spec. But that means that as they develop the API the older versions of landlock need to be less restrictive than newer versions otherwise programs dont work across kernel versions.
That way, a program that is very restrictive on say kernel 6.30 can also run on kernel 6.1 with less restrictions. The program keeps functioning the same way (never break userspace). The only way to do that is to have the developer tell what parts need to be restricted explicitly and you can't restrict what isn't implemented yet.
They're planning to extend it to all socket types. This is also mentioned in the linked article https://github.com/landlock-lsm/linux/issues/6
I guess if you want to run without networking at all today you can just unshare into a fresh network namespace, or maybe use seccomp strict mode
There's always a lot of caution and review that goes into a new syscall feature, because once you add a feature, there's no takebacks. All the libraries downstream from landlock rely on the kernel API being good.
There is an ongoing patch series for udp and another one for general socket control.
You can read about it on the linux-security-module mailing list.
Basically UDP is harder to hook into because it's a connectionless protocol. So bind and connect don't really work the same way.
https://lore.kernel.org/all/20241214184540.3835222-1-matthie...
https://lore.kernel.org/linux-security-module/20251118134639...
oof! thats terrible... :/ good to know..... what a weird restriction.
I think it's only "weird" if you don't understand why it is the case... adding UDP/raw socket support is much more difficult, and waiting to get that implemented would have much larger downsides for the project as a whole to gain any traction in the meantime.
Well that seems like a major oversight there...what is the reasoning for that?