OpenVZ Forum - RDF feed
type: channel
items: [RFC PATCH 1/2] capabilities: define CONFIG_COMMONCAP
items: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)
items: [PATCH RFC] cgroups: implement device whitelist cgroup+lsm
items: Re: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)

[RFC PATCH 1/2] capabilities: define CONFIG_COMMONCAP
type: item
description: >From 1512a99aedb7a75ac993ccef91a42c97e1baefc5 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Fri, 28 Sep 2007 10:33:33 -0500 Subject: [PATCH 1/2] capabilities: define CONFIG_COMMONCAP currently the compilation of commoncap.c is determined through Makefile logic. So there is no single CONFIG variable which can be relied upon to know whether it will be compiled. Define CONFIG_COMMONCAP to be true when lsm is not compiled in, or when the capability or rootplug modules are compiled. These are the cases when commoncap is currently compiled. Use this variable in security/Makefile to determine commoncap.c's compilation. Apart from being a logic cleanup, this is needed by the upcoming cap_bset patch so that prctl can know whether PR_SET_BSET should be supported. Changelog: Nov 15: make CONFIG_FILE_CAPABILITIES just depend on COMMONCAP. Unfortunately since rootplug doesn't hook cap_setxattr, it would be not quite right to allow CONFIG_FILE_CAPABILITIES with rootplug. Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- security/Kconfig | 6 +++++- security/Makefile | 9 +++------ 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/security/Kconfig b/security/Kconfig index 8086e61..de7f9fe 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -80,9 +80,13 @@ config SECURITY_CAPABILITIES This enables the "default" Linux capabilities functionality. If you are unsure how to answer this question, answer Y. +config COMMONCAP + bool + default !SECURITY || SECURITY_CAPABILITIES || SECURITY_ROOTPLUG + config SECURITY_FILE_CAPABILITIES bool "File POSIX Capabilities (EXPERIMENTAL)" - depends on (SECURITY=n || SECURITY_CAPABILITIES!=n) && EXPERIMENTAL + depends on COMMONCAP && !SECURITY_ROOTPLUG && EXPERIMENTAL default n help This enables filesystem capabilities, allowing you to give diff --git a/security/Makefile b/security/Makefile index ef87df2..7cccc81 100644 --- a/security/Makefile +++ b/security/Makefile @@ -5,14 +5,11 @@ obj-$(CONFIG_KEYS) += …
creator: serue
date: 2007-11-15T23:16:15-00:00

[PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)
type: item
description: >From 9ba95f1dbf88a512ffd423f6ccd627dc0460b052 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Mon, 12 Nov 2007 16:50:04 -0500 Subject: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7) The capability bounding set is a set beyond which capabilities cannot grow. Currently cap_bset is per-system. It can be manipulated through sysctl, but only init can add capabilities. Root can remove capabilities. By default it includes all caps except CAP_SETPCAP. This patch makes the bounding set per-process. It is inherited at fork from parent. Noone can add elements, CAP_SYS_ADMIN is required to remove them. Perhaps a new capability should be introduced to control the ability to remove capabilities, in order to help prevent running a privileged app with enough privs to be dangerous but not enough to be successful. One example use of this is to start a safer container. For instance, until device namespaces or per-container device whitelists are introduced, it is best to take CAP_MKNOD away from a container. Two questions: 1. I set CAP_FULL_SET and CAP_INIT_EFF_SET to contain only valid capabilities. Does that seem like a future maintenance headache? We only want the capability bounding set returned from kernel to container valid capabilities, so having CAP_FULL_SET contain all capabilities would mean that on every cap_prctl_getbset() we'd have to either manually clear invalid bits or let userspace sort it out. 2. Would getting and setting the bounding sets be better done through syscall? That better mirrors the capset+capget, but using prctl better mirrors the keep_capabilities setting. The following test program will get and set the bounding set. For instance ./bset get (lists capabilities in bset) ./bset strset cap_sys_admin (starts shell with new bset) (use capset, setuid binary, or binary with file capabilities to try to increase caps) =========================================================== bset.c: ========================…
creator: serue
date: 2007-11-15T23:17:52-00:00

[PATCH RFC] cgroups: implement device whitelist cgroup+lsm
type: item
description: (This patch is based against the same CONFIG_COMMONCAP patch as the capability bounding set patch I just sent out) >From fcbd0bd0a8ee1e37a68f5381b47ec0746cb9b1cc Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Thu, 11 Oct 2007 15:27:48 -0400 Subject: [PATCH 2/2] cgroups: implement device whitelist cgroup+lsm Implement a cgroup using the LSM interface to enforce open and mknod on device files. Not a line of this code is expected to be used in a final version, this is just a proof of concept to explore whether we can or should use an LSM for this purpose until device namespaces are really needed. The alternative is to simply set up a static /dev for each container and remove CAP_MKNOD from the container's bounding set. Several people feel that that approach is insufficient. This patch implements a simple device access whitelist. A whitelist entry has 4 fields. 'type' is a (all), c (char), or b (block). 'all' means it applies to all types, all major numbers, and all minor numbers. Major and minor are obvious. Access is a composition of r (read), w (write), and m (mknod). The root devcgroup starts with rwm to 'all'. A child devcg gets a copy of the parent. Admins can then add and remove devices to the whitelist. Once CAP_HOST_ADMIN is introduced it will be needed to add entries as well or remove entries from another cgroup, though just CAP_SYS_ADMIN will suffice to remove entries for your own group. An entry is added by doing "echo <type> <maj> <min> <access>" > devcg.allow, for instance: echo b 7 0 mrw > /cgroups/1/devcg.allow An entry is removed by doing likewise into devcg.deny. Since this is a pure whitelist, not acls, you can only remove entries which exist in the whitelist. You must explicitly echo a 0 0 mrw > /cgroups/1/devcg.deny to remove the "allow all" entry which is automatically inherited from the root cgroup. While composing this with the ns_cgroup may seem logical, it may not be the right thing to do. Note that each newly created d…
creator: serue
date: 2007-11-15T23:23:25-00:00

Re: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)
type: item
description: Serge, I've been thinking a lot about this one. As an alternative implementation, have you considered changing one bounding capability bit per system call? Something like this: prctl(PR_CAPBSET_READ, CAPVERSION, CAP_NET_RAW); returns -> 1(allowed) or 0(blocked) prctl(PR_CAPBSET_DROP, CAPVERSION, CAP_NET_RAW) returns -> 0(success) or -EPERM; I also think we should use CAP_SETPCAP for the privilege of manipulating the bounding set. In many ways irrevocably removing a permission requires the same level of due care as adding one (to pI). This has scalability designed in, at the expense of more system calls to get the same (rare) work done. Cheers Andrew Serge E. Hallyn wrote: >>From 9ba95f1dbf88a512ffd423f6ccd627dc0460b052 Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <serue@us.ibm.com> > Date: Mon, 12 Nov 2007 16:50:04 -0500 > Subject: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7) > > The capability bounding set is a set beyond which capabilities > cannot grow. Currently cap_bset is per-system. It can be > manipulated through sysctl, but only init can add capabilities. > Root can remove capabilities. By default it includes all caps > except CAP_SETPCAP. > > This patch makes the bounding set per-process. It is inherited > at fork from parent. Noone can add elements, CAP_SYS_ADMIN is > required to remove them. Perhaps a new capability should be > introduced to control the ability to remove capabilities, in > order to help prevent running a privileged app with enough > privs to be dangerous but not enough to be successful. > > One example use of this is to start a safer container. For > instance, until device namespaces or per-container device > whitelists are introduced, it is best to take CAP_MKNOD away > from a container. > > Two questions: > > 1. I set CAP_FULL_SET and CAP_INIT_EFF_SET to contain > only valid capabilities. Does that seem like a future maintenance > headache? We only want the capability bounding set returned from kerne…
creator: Andrew Morgan
date: 2007-11-16T17:18:03-00:00

Re: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)
type: item
description: Quoting Andrew Morgan (morgan@kernel.org): > Serge, > > I've been thinking a lot about this one. As an alternative > implementation, have you considered changing one bounding capability bit > per system call? Something like this: > > prctl(PR_CAPBSET_READ, CAPVERSION, CAP_NET_RAW); > returns -> 1(allowed) or 0(blocked) > prctl(PR_CAPBSET_DROP, CAPVERSION, CAP_NET_RAW) > returns -> 0(success) or -EPERM; Interesting. Didn't like it on first read, but it certainly has its appeal. Sure, I'll whip something like this up. > I also think we should use CAP_SETPCAP for the privilege of manipulating > the bounding set. In many ways irrevocably removing a permission > requires the same level of due care as adding one (to pI). Aside from being heavy-handed, it also means that we are restricting the use of per-process capability bounding sets to kernels with file capabilities compiled in, right? Are we ok with that? > This has scalability designed in, at the expense of more system calls to > get the same (rare) work done. > > Cheers > > Andrew Thanks, -serge > > Serge E. Hallyn wrote: > >>From 9ba95f1dbf88a512ffd423f6ccd627dc0460b052 Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <serue@us.ibm.com> > > Date: Mon, 12 Nov 2007 16:50:04 -0500 > > Subject: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7) > > > > The capability bounding set is a set beyond which capabilities > > cannot grow. Currently cap_bset is per-system. It can be > > manipulated through sysctl, but only init can add capabilities. > > Root can remove capabilities. By default it includes all caps > > except CAP_SETPCAP. > > > > This patch makes the bounding set per-process. It is inherited > > at fork from parent. Noone can add elements, CAP_SYS_ADMIN is > > required to remove them. Perhaps a new capability should be > > introduced to control the ability to remove capabilities, in > > order to help prevent running a privileged app with enough > > privs to be dangerous but not enough…
creator: serue
date: 2007-11-17T03:42:26-00:00

Re: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)
type: item
description: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Serge E. Hallyn wrote: >> I also think we should use CAP_SETPCAP for the privilege of manipulating >> the bounding set. In many ways irrevocably removing a permission >> requires the same level of due care as adding one (to pI). > > Aside from being heavy-handed, it also means that we are restricting the > use of per-process capability bounding sets to kernels with file > capabilities compiled in, right? Are we ok with that? > I am. :-) Cheers Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFHPmyQQheEq9QabfIRAnnbAJ0c22LPNc1EnjWyvR4ZrwcyAiJDrgCeOdTj TJFJwUK7UMkeX5M9ULzbN44= =LMQP -----END PGP SIGNATURE----- _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Andrew Morgan
date: 2007-11-17T04:22:42-00:00