alt Hacker NewsThis position is trivially incorrect as it makes the entire concept of a login shell impossible in the first place, as you have just described the regime in which login, su, and even basic tools like ping (which have the permission to use raw sockets and write ICMP even though we would never let any of its parents do so) operate.
Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.
But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.
The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.
Yes, and macOS entitlements work similarly, as you know. I was interpreting “what it expects its children should be able to do” as a single rule for all child processes, like in OpenBSD pledge() which the parent seems to be referring to. Sure, such a rule could securely be greater than the parent’s own permissions if you strictly limit what processes can be executed with what arguments.
Actually, there’s another exception to my previous statement that I should have mentioned. For mitigations that are meant to prevent an attacker from turning memory corruption into code execution or code-execution-like control – such as restrictions on mapping memory executable (at least that’s one purpose for such restrictions), or memory map lockdown – the mitigations’ effectiveness doesn’t depend on whether they’re applied to children. Those mitigations are sometimes treated as part of the sandbox system, sometimes separate.