Messages in this thread | | | Date | Thu, 17 Nov 2011 20:24:24 +0400 | From | Cyrill Gorcunov <> | Subject | Re: [RFC] Introduce CAP_CHECKPOINT capability and filter map_files/ access |
| |
On Thu, Nov 17, 2011 at 09:41:05AM -0600, Serge E. Hallyn wrote: > 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? >
There is lock_trace() call which should prevent from accessing non-own map_files (if only CAP_SYS_PTRACE is not granted).
> 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)
The patches for kernel (which needed at moment) are placed at http://goo.gl/DwYHx , I didn't pushed them for reivew yet since they are not well stable and need some rework, so you could take a look if you're interested. Feedback is appreciated as always, but I warned you, they are not yet for inclusion ;)
> > 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
Thanks a lot for taking a view, Serge!
Cyrill
| |