On Mon, Jun 1, 2009 at 6:35 AM, Serge E. Hallyn <serue@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
