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 09:41:05 -0600
From:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
To:	Cyrill Gorcunov <gorcunov@...il.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

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?

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
--
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/