Messages in this thread | | | Date | Thu, 17 Nov 2011 15:07:13 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC] Introduce CAP_CHECKPOINT capability and filter map_files/ access |
| |
Quoting Andrew Morton (akpm@linux-foundation.org): > On Thu, 17 Nov 2011 09:41:05 -0600 > "Serge E. Hallyn" <serge.hallyn@canonical.com> wrote: > > > > - (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. > > yup. > > From a development-order perspective perhaps it is better to get > everything working and stabilized for root first. Then as a separate > activity start working on making it available to less-privileged users. > > We would need to be confident that such a second development effort > doesn't cause back-compatibility issues (ie: interface changes) for > existing root users. > > > > Is it possible that once everything is working for root, we realise > that we can get it all working for non-root users via suitable setuid > userspace tools?
Not only that, I think it's possible that by the time all the needed c/r pieces are in, user namespaces will be as well, as will unprivileged namespace cloning (at least when done along with CLONE_NEWUSER). In that case, it should be possible to do c/r of a container with no privileges on the host (but full privileges to the user namespace of the container).
-serge
| |