[CRIU] [PATCH] cr-super: Initial commit

Pavel Emelyanov xemul at parallels.com
Wed Sep 16 07:13:41 PDT 2015


> +enum {
> +	SUPER_RSP_OK				= 1,
> +	SUPER_RSP_ERR				= 2,
> +
> +	SUPER_REQ_EXIT				= 3,
> +
> +	SUPER_REQ_MFD_OPEN_DIR			= 4,
> +	SUPER_REQ_MFD_FILL_STAT			= 5,
> +	SUPER_REQ_MFD_FILL_LINK			= 6,
> +	SUPER_REQ_MFD_FILL_MNT_ID		= 7,
> +
> +	SUPER_REQ_MAX
> +};

Right now (plz, add this to the patch commit message next time ;) we
only need super-power to open the /proc/$pid/map_files/$link links.
In turn, these links are used by criu to perform these checks:

1. open the mapped file to collect and dump info about it
   `- a. get file's mnt_id
   `- check for file type being regular or /dev/zero
2. generate ID for shared memory segments
3. dumping mapped and unlinked file

It's also used to fixup aufs and overlayfs bugs, but we can forget 
about it, since aufs is going to be no-longer-required thing and 
overlayfs bugs are already fixed in the kernel.

All items can be get w/o map_files just by analyzing the smaps output,
so getting this with suid proggie for attache-able tasks doesn't seem
to break security. Except two things -- opening the file and dumping
it's contents if it's unlinked.

Let's check this thing carefully.

1. open to get file's mnt_id

Getting the exact mount-id for a file is already done via /proc/pid/fdinfo,
revealing this for mapped files doesn't seem to break security.

2. Dumping mapped and unlinked file

If we can attach to a task with ptrace we can read the mapped file via
the memory region, doing this via opened map_files link does the same
but _much_ faster, so this also is not a security violation.

3. Opening the file to git its path reliably

We can already know a file path via maps/smaps, we also know its device
and inode numbers, so getting the path using this data (and checking it
to be the correct one) is possible, just it's more convenient to get one
via opened map_files link, so here we're also seem to be safe.


It would be great if Florian could check whether we're on the right
track from the security POV.

-- Pavel



More information about the CRIU mailing list