Introduce CAP_CHECKPOINT capability and filter map_files/ access

RFC In review Cyrill Gorcunov 3 participants 6 messages Nov 17, 2011

Subsystems (2)

Proc filesystem Capabilities

lore

Share & tools

lore

Cyrill Gorcunov

author

2011-11-17 10:04 UTC #0 lore raw

RFC 1/1 Introduce CAP_CHECKPOINT capability and filter map_files/ access

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/
- (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).

(the patch is on top of -mm)

*NOT-FOR-INCLUSION*

---
 fs/proc/base.c             |    6 ++++--
 include/linux/capability.h |    7 ++++++-
 2 files changed, 10 insertions(+), 3 deletions(-)

fs/proc/base.c +4 -2

Index: linux-2.6.git/fs/proc/base.c
===================================================================
@@ -2386,7 +2386,8 @@ static struct dentry *proc_map_files_loo
 	struct mm_struct *mm;
 
 	result = ERR_PTR(-EACCES);
-	if (!capable(CAP_SYS_ADMIN))
+	if (!capable(CAP_SYS_ADMIN) &&
+	    !capable(CAP_CHECKPOINT))
 		goto out;
 
 	result = ERR_PTR(-ENOENT);

@@ -2442,7 +2443,8 @@ proc_map_files_readdir(struct file *filp
 	int ret;
 
 	ret = -EACCES;
-	if (!capable(CAP_SYS_ADMIN))
+	if (!capable(CAP_SYS_ADMIN) &&
+	    !capable(CAP_CHECKPOINT))
 		goto out;
 
 	ret = -ENOENT;

include/linux/capability.h +6 -1

Index: linux-2.6.git/include/linux/capability.h
===================================================================
@@ -360,8 +360,13 @@ struct cpu_vfs_cap_data {
 
 #define CAP_WAKE_ALARM            35
 
+/*
+ * Allow to use privilege operations needed for
+ * checkpoint/restore procedure.
+ */
+#define CAP_CHECKPOINT             36
 
-#define CAP_LAST_CAP         CAP_WAKE_ALARM
+#define CAP_LAST_CAP         CAP_CHECKPOINT
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)

Serge E. Hallyn

2011-11-17 15:41 UTC #1 lore raw

Quoted 10 lines · Cyrill Gorcunov

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.

Quoted 7 lines

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

Cyrill Gorcunov

author

2011-11-17 16:25 UTC #2 lore raw

Quoted 5 lines · Serge E. Hallyn

Quoted 4 lines · Cyrill Gorcunov
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.

Quoted 9 lines

Quoted 6 lines
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).

Quoted 12 lines

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.
Quoted 4 lines
- (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

Quoted 7 lines

Quoted 3 lines
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 ;)

Quoted 5 lines

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

Andrew Morton

2011-11-17 20:54 UTC #3 lore raw

In reply to Serge E. Hallyn

Quoted 8 lines · On Thu, 17 Nov 2011 09:41:05 -0600 "Serge E. Hallyn"…

Quoted 7 lines
- (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).

Quoted 6 lines

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.

Quoted 1 line

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?

Serge E. Hallyn

2011-11-17 21:07 UTC #4 lore raw

Quoted 30 lines · Andrew Morton

Quoted 8 lines · On Thu, 17 Nov 2011 09:41:05 -0600 "Serge E. Hallyn"…
Quoted 7 lines
- (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).
Quoted 6 lines
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.

Quoted 3 lines

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

Cyrill Gorcunov

author

2011-11-17 21:32 UTC #5 lore raw

In reply to Andrew Morton

On Thu, Nov 17, 2011 at 12:54:14PM -0800, Andrew Morton wrote:
...

Quoted 14 lines

Quoted 7 lines
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.

Quoted 7 lines

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?

Once it operates well under root (actually I'm testing it under kvm with root account) I believe tuning code up for non-root users should be possible too. At moment I need cap-sys-admin only because of map_files/ but technically I barely need ptrace over dumping task(s) and access to map_files.

Cyrill