Re: [RFC] Introduce CAP_CHECKPOINT capability and filter map_files/ access

["Serge E. Hallyn" <serge.hallyn@canonical.com>]

Quoting Cyrill Gorcunov (gorcunov@gmail.com):
> The goal idea of checkpoint/restore is to provide this feature not
> for admins only but regular users as well. Still some operations
> are privileged -- such as accessing /proc/$pid/map_files.
> 
> So instead of requiring anyone who has a will to checkpoint/restore
> processes CAP_SYS_ADMIN privileges, it might (?) be worth to bring a way
> less powerful CAP_CHECKPOINT capability.
> 
> The following permissions for CAP_CHECKPOINT should be granted
>  - read/write /proc/$pid/map_files/

read/write to all map files, or only pids he owns?

I think a CAP_CHECKPOINT may make sense, but not if includes read/write
to all map files.  That's too much power, and you may as well just hand
him everything.  But, CAP_CHECKPOINT shouldn't need to include that.  You
should be able to get that for instance by being the creator of the user
namespace being checkpointed.  If you really want to checkpoint/restart
anything on the system, then you should be required to be root.  Trying
to easily hand that power to an unprivileged user is more dangerous imo.

>  - (not yet merged) clone-with-specified-pid, might be changed to last_pid+clone setup
>  - (not yet published/stabilized) prctls calls to tune up vDSO and elements
>    of mm_struct such as mm->start_code, mm->end_code, mm->start_data and etc
> 
> I would like to gather people opinions on such approach as a general.
> _ANY_ comments are highly appreciated. Would it worth it or not (since
> CAPs space is pretty limited one).

It's hard to have a specific dialogue without the full c/r patchset and
idea of the architecture of the exploiters (ie c/r and maybe
debuggers)

Sorry, the security implications of the in-kernel c/r syscalls were
pretty simple and clear to me, but those of the new approach are not.

-serge