Comment by the8472
4 years ago
Landlock suffers from the same limitations as seccomp when it comes to pledge-emulation: you can't opt out of inheritance.
4 years ago
Landlock suffers from the same limitations as seccomp when it comes to pledge-emulation: you can't opt out of inheritance.
That's a good thing.
No. Having inheritance a default is fine.
Not having an option to opt out when your program voluntarily tries to secure itself is terrible because it means fewer programs can use it to secure themselves. A classic example would be an ssh server. You want to factor it into several components, one that talks to the network and a privileged (root) part that spawns the child processes with arbitrary uids. The latter part can reasonably pledge away a lot of its privileges but its children must run unrestricted (but often on unprivileged users).
This is a good example that really helps to explain things. SECCOMP's model of monotonically decreasing permissions seems the most intuitive. However with something like an SSH server I imagine the great fear is a remote exec compromise. pledge() fixes that, since after you call pledge, you can't create new PROT_EXEC memory. Plus OpenBSD enforces a W^X invariant so we can say for certain nothing like a pre-existing executable stack gets grandfathered in. So what they're doing seems reasonable to me. It's an added feature that our Linux polyfill can't offer. But that doesn't mean our pledge() doesn't work as advertised. We simply offer a subset of behaviors. It's not a disjoint paradigm that some people here have made it out to be.
All that's required to emulate "no inheritance" is a broker.
6 replies →
No that's a linux thing. The OpenBSD way is to do things that could be abused later early and then drop privs to prevent abuse. How is some program going to know what other programs you use will need? How is the dynamic linker of the later program supposed to deal?
> The OpenBSD way is to do things that could be abused later early and then drop privs to prevent abuse.
That is the approach if you can't regain privileges. In the OpenBSD way it is literally the opposite of waht you propose.
> How is some program going to know what other programs you use will need?
It doesn't? Same issue on linux/openbsd in that regard, with some aspects a bit different due to libc.
> How is the dynamic linker of the later program supposed to deal?
It obviously doesn't, again, same thing on Linux and OpenBSD. It also won't help you to be able to regain privileges via exec if the issue is a shared library.
Allowing for privileges to not propagate is a cool feature that allows you to shell out to a binary that you can't write to (otherwise it's pointless) and have that binary manage its own permissions. That's sometimes important, and Apparmor supports that sort of thing (with child profiles).
But it's also a big footgun that can easily allow a full sandbox bypass.
You can implement the child profile concept easily enough with a privileged broker anyway.
3 replies →