[PATCH 5/9] cr: capabilities: define checkpoint and restore fns

[Serge E. Hallyn]

Quoting Andrew G. Morgan (morgan at kernel.org):
> On Sun, May 31, 2009 at 6:38 PM, Serge E. Hallyn <serge at hallyn.com> wrote:
> >
> > Quoting Andrew G. Morgan (morgan at kernel.org):
> > > Serge,
> > >
> > > I'm not sure I'm too happy with hard coding the 64-bitness of
> > > capability sets. It may well be a very long time before we increase
> > > their size, but couldn't you prepare for that with some reference to
> > > the prevailing magic numbers for the current ABI representation?
> >
> > Hmm, ok.  I figured since the c/r code was in capability.h it would
> > be obvious that going past 64-bit would mean a new checkpoint image
> > format.  I can see where that's silly...
> >
> > I'll put in a commented BUILD_BUG_ON like Alexey suggests - does that
> > suffice?
> 
> I guess I'm not really well up on what the plans are for checkpoint
> images. Is there some sort of version control/signature/checksum to
> protect a kernel from loading an image that has been hacked to modify
> the privilege it was running with when the checkpoint was created?

No.  One day we expect there will be TPM-signing of checkpoint images,
but that will be up to userspace to properly exploit.  So if userspace
wants to enforce a certain flow control to prevent an unprivileged user
from modifying a checkpoint image (which of course it does), then it
should set up DAC and/or MAC to enforce that.

> > > Also, the use of 'error' as both a variable and a goto destination
> > > looks a little confusing.
> >
> > Ok will change.
> >
> > Did you see any problems with the way I authorize a task's resetting
> > of capabilities at sys_restart()?
> 
> [See above.] Is there a mailing list or something I can lurk on to get
> up to speed on what is being intended?

It mainly gets discussed on the containers list
(https://lists.linux-foundation.org/mailman/listinfo/containers) and
on freenode/#lxcontainers.

thanks,
-serge