7 ms·
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.
by roer 10mo ago
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.
- ape4 10mo agoPretty big loophole!
- parlortricks 10mo agoWell that seems like a major oversight there...what is the reasoning for that?
- arianvanp 10mo agoIt'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 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
- razighter777 10mo agoThere'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-matthieu@buffet.re/ https://lore.kernel.org/all/20241214184540.3835222-1-matthie... https://lore.kernel.org/linux-security-module/20251118134639.3314803-1-ivanov.mikhail1@huawei-partners.com/T/#t https://lore.kernel.org/linux-security-module/20251118134639...
- rini17 10mo agoThey can be disabled by firewall, iptables can match outgoing sockets by owner uid. I know it's not the same thing as landlock, still can come in handy. And raw sockets require elevated privileges anyway iirc.
- habbekrats 10mo agooof! thats terrible... :/ good to know..... what a weird restriction.
- ranger_danger 10mo agoI 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.
- thayne 10mo agoWell you need root access, or at least the CAP_NET_RAW capability to use raw sockets. UDP seems pretty bad though.