Cryptography to the rescue! [LWN.net]

Cryptography to the rescue!

Posted Feb 25, 2010 16:23 UTC (Thu) by quotemstr (subscriber, #45331)
Parent article: A Checkpoint/restart update

Doing things this way will break certain use cases, such as checkpointing a setuid program which has since dropped its privileges, but there is probably no way to make that case work securely for unprivileged users.

The problem with restoring a setuid program is that users might be able to modify the serialized state. Why not use a MAC to authenticate the saved state? Administrators would need to provide a secret key not visible to ordinary users, of course, but that would be trivial to provide via a sysctl.

On the other hand, it seems like it'd be possible to implement this authenticated-checkpoint functionality from userspace by asking a privileged process to do the checkpointing and restoration on behalf of an ordinary user.

(Log in to post comments)

Cryptography to the rescue!

Posted Feb 25, 2010 16:33 UTC (Thu) by hallyn (subscriber, #22558) [Link]

Indeed we definately intend to exploit the TPM, and have it sign valid
checkpoint images.

As for using MAC, you can certainly set up an assured pipeline using
SELinux policy to make sure that noone can modify a checkpoint image,
and that /bin/restart runs in a domain which can only read valid
checkpoint images. Hmm, well, I suppose /bin/restart_wrapper would
only be able to open validated checkpoint images, then pass those in
to /bin/restart (restart itself will need to open all the files used
by the restarted program).

Finally, note that an unprivileged user can neither checkpoint nor
restart a setuid program. It can't checkpoint it because it will fail
the ptrace access checks, and can't restart it because sys_restart() will
try to do cred_setresuid() to an effective userid of 0 and fail (or open
a resource which the unprivileged user cannot access, and fail).