kern: better hierarchical jail semantics for ALLOW_UNPRIV_PARENT_TAMPER

[kevans]

Summary

The operating theory here is that one might want a jail structure like:

prison0

• foo: allow.nounprivileged_parent_tampering
  • bar: allow.unprivileged_parent_tampering

From a high-level view, the above settings effectively say that the
foo uid space is independent of prison0, but bar is expected to be the
same as foo. With the current implementation, prison0 unprivileged
users would be allowed to operate on foo.bar, but not on foo. This is
clearly not the intended behavior.

Add a prison_chain_allow() that evaluates the target jail and all
intermediates to confirm that the given allow bit is set in the entire
path, and use it for PR_ALLOW_UNPRIV_PARENT_TAMPER. This creates the
appropriate barrier for prison0 -> foo.bar in all cases.

[kevans]

Ping?

[zlei]

Not familiar with the ucred part, but the concept looks good to me. I'm adding @olce ( I think he is familiar with ucred) for this.

[jamie]

PR_ALLOW_UNPRIV_PARENT_TAMPER is enough of a corner case (in restricting a parent jail) that I don't foresee anyone else calling prison_chain_allow. But perhaps that's just my own lack of imagination ;-)

[kevans]

In D54992#1301471, @jamie wrote:

PR_ALLOW_UNPRIV_PARENT_TAMPER is enough of a corner case (in restricting a parent jail) that I don't foresee anyone else calling prison_chain_allow. But perhaps that's just my own lack of imagination ;-)

That's a very good point- I might change it to prison_allow_tampering and drop the unsigned argument pre-commit. We've gone this long without having any other weird ones like this, it may be that we don't want to encourage other extensions like it without further design review (and then, this is easy to abstract out) -- the tampering case makes some amount of sense, at least, because it's specifically root forbidding its own users from crossing the boundary.