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

[Andrew G. Morgan]

On Mon, Jun 1, 2009 at 6:35 AM, Serge E. Hallyn <serue at us.ibm.com> wrote:
>> > I'll put in a commented BUILD_BUG_ON like Alexey suggests - does that
>> > suffice?

I can't speak for other subsystems, but it seems to me as if for the
capabilities, I'd want to create something like this in
include/linux/capabilities.h

typedef struct checkpoint_caps_s {
   /* what goes in here is the capability code's business */
} checkpoint_caps_t;

and then have a kernel-internal callable:

   caps_checkpoint_save(&caps_storage);
   caps_checkpoint_restore(&caps_storage);

kind if API. That way, the maintainer of the subsystem state gets to
make sure that the right things are saved/restored/sanity checked.
Breaking things out explicitly in "struct ckpt_hdr_cred" looks like it
will complicate the distribution of knowledge about what's going on
throughout the kernel.

Cheers

Andrew


>>
>> 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.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers