3 ms·

I was also confused, but I get you and now it seems obvious. I think that we have two problems. One is that we want to constrain everything as much as possible

by hawski 5y ago

I was also confused, but I get you and now it seems obvious. I think that we have two problems. One is that we want to constrain everything as much as possible and the second is to allow generic purpose computing. In the first problem we want to allow programs to drop privileges, like a good citizen and also spawn programs with dropped privileges, which requires some sort of inheritance. Modulating the inheritance part seems vital to allow it. As you mentioned the gunzip issue. We could also imagine, that if a program is allowed to run other programs and without inheritance it could just run tee to write files wherever it wants. That's why on Android and other similar systems an app has to declare it's limits. Then it can still do work on behalf of another app via intents - in a way pipe/fork/exec. Limits are not inherited then. You can always limit what the application is allowed to run or communicate with.

wahern 5y ago
Yeah. There's an implicit assumption that some restrictions and capabilities do need to be inherited or passed. /bin/cat can't read /etc/shadow unless it inherits the root UID or is passed a descriptor to the opened file. While the traditional Unix programming environment falls short of an ideal object capabilities model, it doesn't fall that short--the Capsicum API extension is quite simple. Other programming environments, like Android as you point out, have their own intrinsic security model. Discussions about the efficacy of interfaces like pledge, landlock, seccomp, etc, are set against these background models and the existing software ecosystems they support. The argument for pledge and unveil isn't that it's conceptually superior to, e.g., a pure object capabilities system; it's that in practice it's the interface most likely to be used effectively by software in the Unix programming environment to augment the existing model.

by hawski 5y ago

wahern 5y ago

Yeah. There's an implicit assumption that some restrictions and capabilities do need to be inherited or passed. /bin/cat can't read /etc/shadow unless it inherits the root UID or is passed a descriptor to the opened file. While the traditional Unix programming environment falls short of an ideal object capabilities model, it doesn't fall that short--the Capsicum API extension is quite simple. Other programming environments, like Android as you point out, have their own intrinsic security model. Discussions about the efficacy of interfaces like pledge, landlock, seccomp, etc, are set against these background models and the existing software ecosystems they support. The argument for pledge and unveil isn't that it's conceptually superior to, e.g., a pure object capabilities system; it's that in practice it's the interface most likely to be used effectively by software in the Unix programming environment to augment the existing model.