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.
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.
They 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.
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, NASA tried that originally but didn't have the budget, and in that sense it's better late than never to fund something different.
The reasoning as presented just doesn't reflect reality.
This is what I use and it works great. I mainly use it to download things like 3-hour music playlists ahead of long drives to avoid wasting mobile bandwidth.
There is a youtuber (Gneiss Name) making educational content through the medium of Minecraft.
He's made one on OKLab as well: https://youtu.be/nJlZT5AE9zY
The problem is obviously real, but a lot of people disagree with this proposed solution. Nobody is trying to argue whether child abuse is a problem or not.
I don't think there's a workable solution that both protects kids and protects society from sliding into 1984.
It essentially feels like a referendum on "should we just accept it?" It being whichever over those you think is the lesser over two evils. Figuring that out is an exercise left to the reader.
Maybe not let your kids unattended on the internet. Require default settings on vendor products to child protected mode, punish parent negligence while in parallel crawl the web for illegal content.
Ah yeah. It's no wonder people keep mentioning Copenhagen without telling its dirty little secret. It stayed liveable _despite_ the scourge of urbanism because a third of its population was forcibly (via economic forces) displaced during 1970-s, and it _still_ has not reached the 1969 peak: https://www.macrotrends.net/global-metrics/cities/20894/cope...
So it was able to avoid the effects of the density-misery spiral. But it'll get to experience them soon. The transit will become more crowded, traffic more jammed, the crime will go up, and the housing costs (of course) will skyrocket.
