linux-kernel - Re: [RFC] Introduce CAP_CHECKPOINT capability and filter map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Nov 2011 20:24:24 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	LKML <linux-kernel@...r.kernel.org>
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@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/