Messages in this thread | | | Date | Thu, 17 Nov 2011 12:54:14 -0800 | From | Andrew Morton <> | Subject | Re: [RFC] Introduce CAP_CHECKPOINT capability and filter map_files/ access |
| |
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?
| |