job shell should verify jobspec

[garlick]

Assuming flux-framework/flux-security#96 results in basic imp exec functionality, with the shell fetching the unsigned jobspec and R from the instance as it does now, this issue is about adding the mechanism for the shell to validate that it has the same jobspec as was validated by the IMP. The system is not safe until this mechanism is implemented.

[grondo]

Is this actually a flux-core issue? When configured with flux-security, should the job shell just fetch J instead of jobspec from the kvs and unwrap it to check validity?

[garlick]

Wouldn't any attack have to first bypass the imp exec user restriction (e.g. only flux user can switch users)?

I guess if someone hacked the flux account, then one could just overwrite the unsigned jobspec in the KVS for any job? The IMP would validate J but then the shell would fetch the modified jobspec and run it?

Since the imp also restricts shell paths, it does seem like unwrapping J at the shell level would be sufficient to thwart such an attack. Although, is there a TOCTOU attack where J is changed after the IMP validates it but before the shell fetches it? But then at worst, the attacker could only switch the user's request to something that was already signed by the user.

In any case, maybe we have some time to discuss this with @dun as long as the imp exec user restriction is there as a first line of defense?

[grondo]

I guess if someone hacked the flux account, then one could just overwrite the unsigned jobspec in the KVS for any job? The IMP would validate J but then the shell would fetch the modified jobspec and run it?

Yeah, I assumed this possibility was the original purpose of this issue. My only point was that while the job shell fetches jobspec and/or J from the kvs of the enclosing instance, there is nothing the imp can do to "ensure job shell can trust jobspec input", so I suggest moving this issue to flux-core.

Although, is there a TOCTOU attack where J is changed after the IMP validates it but before the shell fetches it? But then at worst, the attacker could only switch the user's request to something that was already signed by the user.

The original concept was that the IMP would pass along the unwrapped jobspec to the job shell, since it already has the unwrapped version of it. However, if the job shell also fetches J and verifies it, then this would be unnecessary.

In any case, maybe we have some time to discuss this with @dun as long as the imp exec user restriction is there as a first line of defense?

Yes, so I vote move the issue to flux-core, since it is a job shell issue, and remove from the current instance milestone?

[garlick]

OK sounds good. Just wanted to be sure I understood.

[grondo]

Transferred from flux-security. The imp doesn't have purview to control how the job shell verifies the integrity of the jobspec, since currently the shell fetches this directly from the instance. As discussed above, if the instance is running as a potentially untrusted user, the job shell should fetch the signed J instead of jobspec, and directly verify the signature. As @garlick mentions, this may not be a requirement initially since we can lock down the IMP to a specific user.