[RFC] [PATCH] file posix capabilities

[RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

This patch implements file (posix) capabilities.  This allows
a binary to gain a subset of root's capabilities without having
the file actually be setuid root.

There are some other implementations out there taking various
approaches.  This patch keeps all the changes within the
capability LSM, and stores the file capabilities in xattrs
named "security.capability".  First question is, do we want
this in the kernel?  Second is, is this sort of implementation
we'd want?

Some userspace tools to manipulate the fscaps are at
www.sr71.net/~hallyn/fscaps/.  For instance,

	setcap writeroot "cap_dac_read_search,cap_dac_override+eip"

allows the 'writeroot' testcase to write to /root/ab when
run as a normal user.

This patch doesn't address the need to update
cap_bprm_secureexec().

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
 include/linux/security.h |   10 +++-
 security/Kconfig         |   11 ++++
 security/capability.c    |    5 ++
 security/commoncap.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 152 insertions(+), 1 deletions(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index f753038..9f90f01 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -47,8 +47,14 @@ extern void cap_capset_set (struct task_
 extern int cap_bprm_set_security (struct linux_binprm *bprm);
 extern void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe);
 extern int cap_bprm_secureexec(struct linux_binprm *bprm);
+extern void cap_d_instantiate(struct dentry *dentry, struct inode *inode);
 extern int cap_inode_setxattr(struct dentry *dentry, char *name, void *value, size_t size, int flags);
 extern int cap_inode_removexattr(struct dentry *dentry, char *name);
+extern int cap_inode_alloc_security(struct inode *inode);
+extern void cap_inode_free_security(struct inode *inode);
+extern void cap_inode_free_security(struct inode *inode);
+extern void cap_inode_post_setxattr(struct dentry *dentry, char *name,
+                                        void *value, size_t size, int flags);
 extern int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid, int flags);
 extern void cap_task_reparent_to_init (struct task_struct *p);
 extern int cap_syslog (int type);
@@ -2684,7 +2690,9 @@ static inline int security_sem_semop (st
 }
 
 static inline void security_d_instantiate (struct dentry *dentry, struct inode *inode)
-{ }
+{
+	cap_d_instantiate(dentry, inode);
+}
 
 static inline int security_getprocattr(struct task_struct *p, char *name, void *value, size_t size)
 {
diff --git a/security/Kconfig b/security/Kconfig
index 67785df..c1fceda 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -80,6 +80,17 @@ config SECURITY_CAPABILITIES
 	  This enables the "default" Linux capabilities functionality.
 	  If you are unsure how to answer this question, answer Y.
 
+config SECURITY_FS_CAPS
+	boolean "Filesystem POSIX capabilities"
+	depends on SECURITY_CAPABILITIES
+	help
+	  This enables filesystem capabilities.  These allow you to
+	  give a subset of root's powers to specific binaries without
+	  making the binaries setuid 0.
+	  This will require another patch in order to work with
+	  selinux enabled.
+	  If you are unsure how to answer this question, answer N.
+
 config SECURITY_ROOTPLUG
 	tristate "Root Plug Support"
 	depends on USB && SECURITY
diff --git a/security/capability.c b/security/capability.c
index b868e7e..67f9388 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -39,6 +39,11 @@ static struct security_operations capabi
 
 	.inode_setxattr =		cap_inode_setxattr,
 	.inode_removexattr =		cap_inode_removexattr,
+	.inode_alloc_security =		cap_inode_alloc_security,
+	.inode_free_security =		cap_inode_free_security,
+	.inode_post_setxattr =		cap_inode_post_setxattr,
+
+	.d_instantiate =                cap_d_instantiate,
 
 	.task_post_setuid =		cap_task_post_setuid,
 	.task_reparent_to_init =	cap_task_reparent_to_init,
diff --git a/security/commoncap.c b/security/commoncap.c
index f50fc29..7504c84 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -24,6 +24,11 @@ #include <linux/ptrace.h>
 #include <linux/xattr.h>
 #include <linux/hugetlb.h>
 
+struct cap_isec {
+	struct semaphore sem;
+	kernel_cap_t inheritable, permitted, effective;
+};
+
 int cap_netlink_send(struct sock *sk, struct sk_buff *skb)
 {
 	NETLINK_CB(skb).eff_cap = current->cap_effective;
@@ -111,6 +116,9 @@ void cap_capset_set (struct task_struct 
 
 int cap_bprm_set_security (struct linux_binprm *bprm)
 {
+#ifdef CONFIG_SECURITY_FS_CAPS
+	struct inode *inode;
+#endif
 	/* Copied from fs/exec.c:prepare_binprm. */
 
 	/* We don't have VFS support for capabilities yet */
@@ -118,6 +126,17 @@ int cap_bprm_set_security (struct linux_
 	cap_clear (bprm->cap_permitted);
 	cap_clear (bprm->cap_effective);
 
+#ifdef CONFIG_SECURITY_FS_CAPS
+	inode = bprm->file->f_dentry->d_inode;
+	if (inode->i_security) {
+		struct cap_isec *isec = inode->i_security;
+
+		bprm->cap_inheritable = isec->inheritable;
+		bprm->cap_permitted = isec->permitted;
+		bprm->cap_effective = isec->effective;
+	}
+#endif
+
 	/*  To support inheritance of root-permissions and suid-root
 	 *  executables under compatibility mode, we raise all three
 	 *  capability sets for the file.
@@ -210,6 +229,110 @@ int cap_inode_removexattr(struct dentry 
 	return 0;
 }
 
+#ifdef CONFIG_SECURITY_FS_CAPS
+int cap_inode_alloc_security(struct inode *inode)
+{
+	struct cap_isec *isec;
+	
+	isec = kzalloc(sizeof(*isec), GFP_KERNEL);
+	if (!isec)
+		return -ENOMEM;
+	init_MUTEX(&isec->sem);
+	inode->i_security = isec;
+	return 0;
+}
+
+void cap_inode_free_security(struct inode *inode)
+{
+	kfree(inode->i_security);
+}
+
+#define XATTR_CAPS_SUFFIX "capability"
+#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
+void cap_d_instantiate(struct dentry *dentry, struct inode *inode)
+{
+	struct cap_isec *isec;
+	int rc;
+	u32 fscaps[3];
+
+	if (!inode)
+		return;
+	if (!inode->i_op->getxattr)
+		return;
+
+	isec = inode->i_security;
+	down(&isec->sem);
+	if (!dentry)
+		dentry = d_find_alias(inode);
+	rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS,
+				   fscaps, sizeof(fscaps));
+	if (rc < 0 && rc != -ENODATA) {
+		printk(KERN_NOTICE "%s: Error (%d) getting xattr\n",
+				__FUNCTION__, rc);
+		goto out;
+	}
+	if (rc < 0)
+		goto out;
+
+	if (rc != sizeof(fscaps)) {
+		printk(KERN_NOTICE "%s: got wrong size for getxattr (%d)\n",
+					__FUNCTION__, rc);
+		goto out;
+	}
+
+	isec->effective = fscaps[0];
+	isec->inheritable = fscaps[1];
+	isec->permitted = fscaps[2];
+
+out:
+	up(&isec->sem);
+}
+
+void cap_inode_post_setxattr(struct dentry *dentry, char *name,
+                                        void *value, size_t size, int flags)
+{
+	struct cap_isec *isec;
+	struct inode *inode;
+	u32 *fscaps;
+
+	if (strcmp(name, XATTR_NAME_CAPS)) {
+		/* Not an attribute we recognize, so nothing to do. */
+		return;
+	}
+
+	fscaps = value;
+	inode = dentry->d_inode;
+	isec = inode->i_security;
+	if (!isec) {
+		int ret;
+		ret = cap_inode_alloc_security(inode);
+		if (ret)
+			return;
+		isec = inode->i_security;
+	}
+	down(&isec->sem);
+	isec->effective = fscaps[0];
+	isec->inheritable = fscaps[1];
+	isec->permitted = fscaps[2];
+	up(&isec->sem);
+}
+#else
+int cap_inode_alloc_security(struct inode *inode)
+{
+	return 0;
+}
+
+void cap_inode_free_security(struct inode *inode)
+{ }
+
+void cap_d_instantiate(struct dentry *dentry, struct inode *inode)
+{ }
+
+void cap_inode_post_setxattr(struct dentry *dentry, char *name,
+                                        void *value, size_t size, int flags)
+{ }
+#endif
+
 /* moved from kernel/sys.c. */
 /* 
  * cap_emulate_setxuid() fixes the effective / permitted capabilities of
@@ -336,6 +459,10 @@ EXPORT_SYMBOL(cap_bprm_apply_creds);
 EXPORT_SYMBOL(cap_bprm_secureexec);
 EXPORT_SYMBOL(cap_inode_setxattr);
 EXPORT_SYMBOL(cap_inode_removexattr);
+EXPORT_SYMBOL(cap_inode_alloc_security);
+EXPORT_SYMBOL(cap_inode_free_security);
+EXPORT_SYMBOL(cap_inode_post_setxattr);
+EXPORT_SYMBOL(cap_d_instantiate);
 EXPORT_SYMBOL(cap_task_post_setuid);
 EXPORT_SYMBOL(cap_task_reparent_to_init);
 EXPORT_SYMBOL(cap_syslog);
-- 
1.4.1

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Serge E. Hallyn (serue@us.ibm.com):
> This patch implements file (posix) capabilities.  This allows
> a binary to gain a subset of root's capabilities without having
> the file actually be setuid root.
> 
> There are some other implementations out there taking various
> approaches.  This patch keeps all the changes within the
> capability LSM, and stores the file capabilities in xattrs
> named "security.capability".  First question is, do we want
> this in the kernel?  Second is, is this sort of implementation
> we'd want?
> 
> Some userspace tools to manipulate the fscaps are at
> www.sr71.net/~hallyn/fscaps/.  For instance,
> 
> 	setcap writeroot "cap_dac_read_search,cap_dac_override+eip"
> 
> allows the 'writeroot' testcase to write to /root/ab when
> run as a normal user.
> 
> This patch doesn't address the need to update
> cap_bprm_secureexec().
> 
> Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
> ---
>  include/linux/security.h |   10 +++-
>  security/Kconfig         |   11 ++++
>  security/capability.c    |    5 ++
>  security/commoncap.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 152 insertions(+), 1 deletions(-)

Here is a different version which sticks closer to the original
version by Simmonds, in that it simply calls getxattr at
bprm_set_security.  Very inadequate perftesting showed no
overhead, and this makes the patch much smaller and compatible
with SELinux.  Note that this patch changes nothing if
CONFIG_FS_CAPABILITIES is not enabled, which is the default, and
should therefore be safe to include in -mm.

(Also CC:ing lsm list which I forgot to do last time)

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
 security/Kconfig     |   10 ++++++++++
 security/commoncap.c |   48 +++++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 57 insertions(+), 1 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 67785df..aa3558f 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -80,6 +80,16 @@ config SECURITY_CAPABILITIES
 	  This enables the "default" Linux capabilities functionality.
 	  If you are unsure how to answer this question, answer Y.
 
+config SECURITY_FS_CAPABILITIES
+	bool "Filesystem Capabilities"
+	depends on SECURITY_CAPABILITIES
+	default n
+	help
+	  This enables filesystem capabilities, allowing you to give
+	  binaries a subset of root's powers without using setuid 0.
+
+	  If in doubt, answer N.
+
 config SECURITY_ROOTPLUG
 	tristate "Root Plug Support"
 	depends on USB && SECURITY
diff --git a/security/commoncap.c b/security/commoncap.c
index f50fc29..064fbb0 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -109,11 +109,17 @@ void cap_capset_set (struct task_struct 
 	target->cap_permitted = *permitted;
 }
 
+#define XATTR_CAPS_SUFFIX "capability"
+#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
 int cap_bprm_set_security (struct linux_binprm *bprm)
 {
+	ssize_t (*bprm_getxattr)(struct dentry *,const char *,void *,size_t);
+	struct dentry *bprm_dentry;
+	ssize_t rc;
+	u32 fscaps[3];
+
 	/* Copied from fs/exec.c:prepare_binprm. */
 
-	/* We don't have VFS support for capabilities yet */
 	cap_clear (bprm->cap_inheritable);
 	cap_clear (bprm->cap_permitted);
 	cap_clear (bprm->cap_effective);
@@ -134,6 +140,46 @@ int cap_bprm_set_security (struct linux_
 		if (bprm->e_uid == 0)
 			cap_set_full (bprm->cap_effective);
 	}
+
+#ifdef CONFIG_SECURITY_FS_CAPABILITIES
+	/* Locate any VFS capabilities: */
+
+	bprm_dentry = dget(bprm->file->f_dentry);
+	if(!(bprm_dentry->d_inode->i_op &&
+			bprm_dentry->d_inode->i_op->getxattr)) {
+		dput(bprm_dentry);
+		return 0;
+	}
+	bprm_getxattr = bprm_dentry->d_inode->i_op->getxattr;
+
+	rc = bprm_getxattr(bprm_dentry, XATTR_NAME_CAPS, &fscaps,
+						sizeof(fscaps));
+	dput(bprm_dentry);
+
+	/*
+	 * serge: not sure about the return values...
+	 * think about them some more, maybe some should
+	 * return rc.
+	 */
+	if (rc < 0 && rc != -ENODATA) {
+		printk(KERN_NOTICE "%s: Error (%d) getting xattr\n",
+				__FUNCTION__, rc);
+		return 0;
+	}
+	if (rc < 0)
+		return 0;
+
+	if (rc != sizeof(fscaps)) {
+		printk(KERN_NOTICE "%s: got wrong size for getxattr (%d)\n",
+					__FUNCTION__, rc);
+		return 0;
+	}
+
+	bprm->cap_effective = fscaps[0];
+	bprm->cap_inheritable = fscaps[1];
+	bprm->cap_permitted = fscaps[2];
+
+#endif
 	return 0;
 }
 
-- 
1.4.1.1

Re: [RFC] [PATCH] file posix capabilities

[Eric W. Biederman]

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> Quoting Serge E. Hallyn (serue@us.ibm.com):
>> This patch implements file (posix) capabilities.  This allows
>> a binary to gain a subset of root's capabilities without having
>> the file actually be setuid root.
>> 
>> There are some other implementations out there taking various
>> approaches.  This patch keeps all the changes within the
>> capability LSM, and stores the file capabilities in xattrs
>> named "security.capability".  First question is, do we want
>> this in the kernel?  Second is, is this sort of implementation
>> we'd want?
>> 
>> Some userspace tools to manipulate the fscaps are at
>> www.sr71.net/~hallyn/fscaps/.  For instance,
>> 
>> 	setcap writeroot "cap_dac_read_search,cap_dac_override+eip"
>> 
>> allows the 'writeroot' testcase to write to /root/ab when
>> run as a normal user.
>> 
>> This patch doesn't address the need to update
>> cap_bprm_secureexec().

Looking at your ondisk format it doesn't look like you include a
version.  There is no reason to believe the current set of kernel
capabilities is fixed for all time.  So we need some for of
forward/backward compatibility.  Maybe in the cap name?

Eric

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> 
> > Quoting Serge E. Hallyn (serue@us.ibm.com):
> >> This patch implements file (posix) capabilities.  This allows
> >> a binary to gain a subset of root's capabilities without having
> >> the file actually be setuid root.
> >> 
> >> There are some other implementations out there taking various
> >> approaches.  This patch keeps all the changes within the
> >> capability LSM, and stores the file capabilities in xattrs
> >> named "security.capability".  First question is, do we want
> >> this in the kernel?  Second is, is this sort of implementation
> >> we'd want?
> >> 
> >> Some userspace tools to manipulate the fscaps are at
> >> www.sr71.net/~hallyn/fscaps/.  For instance,
> >> 
> >> 	setcap writeroot "cap_dac_read_search,cap_dac_override+eip"
> >> 
> >> allows the 'writeroot' testcase to write to /root/ab when
> >> run as a normal user.
> >> 
> >> This patch doesn't address the need to update
> >> cap_bprm_secureexec().
> 
> Looking at your ondisk format it doesn't look like you include a
> version.  There is no reason to believe the current set of kernel
> capabilities is fixed for all time.

In fact my version knowingly ignores CAP_AUDIT_WRITE and
CAP_AUDIT_CONTROL (because on my little test .iso they didn't exist).
So a version number may make sense.

> So we need some for of
> forward/backward compatibility.  Maybe in the cap name?

You mean as in use 'security.capability_v32" for the xattr name?
Or do you really mean add a cap name to the structure?

thanks,
-serge

Re: [RFC] [PATCH] file posix capabilities

[Eric W. Biederman]

"Serge E. Hallyn" <serue@us.ibm.com> writes:

> In fact my version knowingly ignores CAP_AUDIT_WRITE and
> CAP_AUDIT_CONTROL (because on my little test .iso they didn't exist).
> So a version number may make sense.
>
>> So we need some for of
>> forward/backward compatibility.  Maybe in the cap name?
>
> You mean as in use 'security.capability_v32" for the xattr name?
> Or do you really mean add a cap name to the structure?

I was thinking the xattr name.  But mostly I was looking
for a place where you had possibly stashed a version.

Thinking about it possibly the most portable thing to do
is to assign each cap a well known name.  Say
"security.cap.dac_override" and have a value in there like +1  
add the cap -1 clear the cap.  That at least seems to provide
granularity and some measure of future proofing and some measure of
portability.  The space it would take with those names looks ugly
though.

The practical question is what do you do with a program that
was give a set of capabilities you no longer support? 
Do you run it without any capabilities at all?
Do you give it as many capabilities of what it asked for
   as you can?
Do you complain loudly and refuse to execute it at all?

What is the secure choice that least violates the principle of least surprise?

Eric

Re: [RFC] [PATCH] file posix capabilities

[Nicholas Miell]

On Mon, 2006-08-14 at 21:29 -0600, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
> 
> > In fact my version knowingly ignores CAP_AUDIT_WRITE and
> > CAP_AUDIT_CONTROL (because on my little test .iso they didn't exist).
> > So a version number may make sense.
> >
> >> So we need some for of
> >> forward/backward compatibility.  Maybe in the cap name?
> >
> > You mean as in use 'security.capability_v32" for the xattr name?
> > Or do you really mean add a cap name to the structure?
> 
> I was thinking the xattr name.  But mostly I was looking
> for a place where you had possibly stashed a version.
> 
> Thinking about it possibly the most portable thing to do
> is to assign each cap a well known name.  Say
> "security.cap.dac_override" and have a value in there like +1  
> add the cap -1 clear the cap.  That at least seems to provide
> granularity and some measure of future proofing and some measure of
> portability.  The space it would take with those names looks ugly
> though.
> 
> The practical question is what do you do with a program that
> was give a set of capabilities you no longer support? 
> Do you run it without any capabilities at all?
> Do you give it as many capabilities of what it asked for
>    as you can?
> Do you complain loudly and refuse to execute it at all?
> 
> What is the secure choice that least violates the principle of least surprise?

Make it an arbitrary length bitfield with a defined byte order (little
endian, probably). Bits at offsets greater than the length of the
bitfield are defined to be zero. If the kernel encounters a set bit that
it doesn't recognizes, fail with EPERM. If userspace attempts to set a
bit that the kernel doesn't recognize, fail with EINVAL.

It's extensible (as new capability bits are added, the length of the
bitfield grows), backward compatible (as long as there are no unknown
bits set, it'll still work) and secure (if an unknown bit is set, the
kernel fails immediately, so there's no chance of a "secure" app running
with less privileges than it expects and opening up a security hole).

OTOH, everybody seems to have moved from capability-based security
models on to TE/RBAC-based security models, so maybe this isn't worth
the effort?

-- 
Nicholas Miell <nmiell@comcast.net>

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Nicholas Miell (nmiell@comcast.net):
> On Mon, 2006-08-14 at 21:29 -0600, Eric W. Biederman wrote:
> > "Serge E. Hallyn" <serue@us.ibm.com> writes:
> > 
> > > In fact my version knowingly ignores CAP_AUDIT_WRITE and
> > > CAP_AUDIT_CONTROL (because on my little test .iso they didn't exist).
> > > So a version number may make sense.
> > >
> > >> So we need some for of
> > >> forward/backward compatibility.  Maybe in the cap name?
> > >
> > > You mean as in use 'security.capability_v32" for the xattr name?
> > > Or do you really mean add a cap name to the structure?
> > 
> > I was thinking the xattr name.  But mostly I was looking
> > for a place where you had possibly stashed a version.
> > 
> > Thinking about it possibly the most portable thing to do
> > is to assign each cap a well known name.  Say
> > "security.cap.dac_override" and have a value in there like +1  
> > add the cap -1 clear the cap.  That at least seems to provide
> > granularity and some measure of future proofing and some measure of
> > portability.  The space it would take with those names looks ugly
> > though.

On the one hand, there shouldn't be many executables with capabilities
so even a horrendous abuse of disk space isn't so bad, but on the other
hand, yes, it'd be a horrendous abuse of disk space :)

> > The practical question is what do you do with a program that
> > was give a set of capabilities you no longer support? 
> > Do you run it without any capabilities at all?
> > Do you give it as many capabilities of what it asked for
> >    as you can?
> > Do you complain loudly and refuse to execute it at all?
> > 
> > What is the secure choice that least violates the principle of least surprise?
> 
> Make it an arbitrary length bitfield with a defined byte order (little
> endian, probably). Bits at offsets greater than the length of the
> bitfield are defined to be zero. If the kernel encounters a set bit that
> it doesn't recognizes, fail with EPERM. If userspace attempts to set a
> bit that the kernel doesn't recognize, fail with EINVAL.
> 
> It's extensible (as new capability bits are added, the length of the
> bitfield grows), backward compatible (as long as there are no unknown
> bits set, it'll still work) and secure (if an unknown bit is set, the
> kernel fails immediately, so there's no chance of a "secure" app running
> with less privileges than it expects and opening up a security hole).

Sounds good.

The version number will imply the bitfield length, or do we feel warm
fuzzies if the length is redundantly encoded in the structure?

> OTOH, everybody seems to have moved from capability-based security
> models on to TE/RBAC-based security models, so maybe this isn't worth
> the effort?

One day perhaps, but that day isn't here yet.  People are still using
setuid (see /sbin/passwd), so obviously they're not sufficiently
comfortable using *only* TE/RBAC.

-serge

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Serge E. Hallyn (serge@hallyn.com):
> > Make it an arbitrary length bitfield with a defined byte order (little
> > endian, probably). Bits at offsets greater than the length of the
> > bitfield are defined to be zero. If the kernel encounters a set bit that
> > it doesn't recognizes, fail with EPERM. If userspace attempts to set a
> > bit that the kernel doesn't recognize, fail with EINVAL.
> > 
> > It's extensible (as new capability bits are added, the length of the
> > bitfield grows), backward compatible (as long as there are no unknown
> > bits set, it'll still work) and secure (if an unknown bit is set, the
> > kernel fails immediately, so there's no chance of a "secure" app running
> > with less privileges than it expects and opening up a security hole).
> 
> Sounds good.
> 
> The version number will imply the bitfield length, or do we feel warm
> fuzzies if the length is redundantly encoded in the structure?

nm, 'encoded in the structure' clearly is silly.

-serge

Re: [RFC] [PATCH] file posix capabilities

[Nicholas Miell]

On Tue, 2006-08-15 at 07:20 -0500, Serge E. Hallyn wrote:
> Quoting Serge E. Hallyn (serge@hallyn.com):
> > > Make it an arbitrary length bitfield with a defined byte order (little
> > > endian, probably). Bits at offsets greater than the length of the
> > > bitfield are defined to be zero. If the kernel encounters a set bit that
> > > it doesn't recognizes, fail with EPERM. If userspace attempts to set a
> > > bit that the kernel doesn't recognize, fail with EINVAL.
> > > 
> > > It's extensible (as new capability bits are added, the length of the
> > > bitfield grows), backward compatible (as long as there are no unknown
> > > bits set, it'll still work) and secure (if an unknown bit is set, the
> > > kernel fails immediately, so there's no chance of a "secure" app running
> > > with less privileges than it expects and opening up a security hole).
> > 
> > Sounds good.
> > 
> > The version number will imply the bitfield length, or do we feel warm
> > fuzzies if the length is redundantly encoded in the structure?
> 
> nm, 'encoded in the structure' clearly is silly.
> 

There isn't really a version number, just recognized and unrecognized
capability bits. If you wanted, you could use a single byte to give a
binary CAP_DAC_OVERRIDE, with capability bits 8-30 being "stored" in
not-present bytes and therefore assumed to be zero.

-- 
Nicholas Miell <nmiell@comcast.net>

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Nicholas Miell (nmiell@comcast.net):
> On Tue, 2006-08-15 at 07:20 -0500, Serge E. Hallyn wrote:
> > Quoting Serge E. Hallyn (serge@hallyn.com):
> > > > Make it an arbitrary length bitfield with a defined byte order (little
> > > > endian, probably). Bits at offsets greater than the length of the
> > > > bitfield are defined to be zero. If the kernel encounters a set bit that
> > > > it doesn't recognizes, fail with EPERM. If userspace attempts to set a
> > > > bit that the kernel doesn't recognize, fail with EINVAL.
> > > > 
> > > > It's extensible (as new capability bits are added, the length of the
> > > > bitfield grows), backward compatible (as long as there are no unknown
> > > > bits set, it'll still work) and secure (if an unknown bit is set, the
> > > > kernel fails immediately, so there's no chance of a "secure" app running
> > > > with less privileges than it expects and opening up a security hole).
> > > 
> > > Sounds good.
> > > 
> > > The version number will imply the bitfield length, or do we feel warm
> > > fuzzies if the length is redundantly encoded in the structure?
> > 
> > nm, 'encoded in the structure' clearly is silly.
> > 
> 
> There isn't really a version number, just recognized and unrecognized

Well, there is, defined in include/linux/capability.h, but it has never
changed thus far, and tying it to the bitfield length could get ugly as
things change.

In the below patch, the length is simply defined in
include/linux/capability.h, nothing fancy.  If anything beyond the known
capability bits is set to 1, we refuse exec permission.

> capability bits. If you wanted, you could use a single byte to give a
> binary CAP_DAC_OVERRIDE, with capability bits 8-30 being "stored" in
> not-present bytes and therefore assumed to be zero.

From: Serge E. Hallyn <serue@us.ibm.com>
Subject: [PATCH 1/1] security: introduce fs caps

Implement filesystem posix capabilities.  This allows programs to
be given a subset of root's powers regardless of who runs them,
without having to use setuid and giving the binary all of root's
powers.

This version works with Kaigai Kohei's userspace tools, found at
http://www.kaigai.gr.jp/pub/fscaps-1.0-kg.src.rpm under
http://www.kaigai.gr.jp/index.php?FrontPage#b556e50d.

Changelog:
	Aug 15:
	Handle endianness of xattrs.
	Enforce capability version match between kernel and disk.
	Enforce that no bits beyond the known max capability are
	set, else return -EPERM.
	With this extra processing, it may be worth reconsidering
	doing all the work at bprm_set_security rather than
	d_instantiate.

	Aug 10:
	Always call getxattr at bprm_set_security, rather than
	caching it at d_instantiate.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
 include/linux/capability.h |    2 +
 security/Kconfig           |   10 +++++
 security/commoncap.c       |   85 +++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 96 insertions(+), 1 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 6548b35..8b1932c 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -288,6 +288,8 @@ #define CAP_AUDIT_WRITE      29
 
 #define CAP_AUDIT_CONTROL    30
 
+#define CAP_NUMCAPS	     30
+
 #ifdef __KERNEL__
 /* 
  * Bounding set
diff --git a/security/Kconfig b/security/Kconfig
index 67785df..ce2bac7 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -80,6 +80,16 @@ config SECURITY_CAPABILITIES
 	  This enables the "default" Linux capabilities functionality.
 	  If you are unsure how to answer this question, answer Y.
 
+config SECURITY_FS_CAPABILITIES
+	bool "Filesystem Capabilities"
+	depends on SECURITY_CAPABILITIES
+	default n
+	help
+	  This enables filesystem capabilities, allowing you to give
+	  binaries a subset of root's powers without using setuid 0.
+
+	  If in doubt, answer N.
+
 config SECURITY_ROOTPLUG
 	tristate "Root Plug Support"
 	depends on USB && SECURITY
diff --git a/security/commoncap.c b/security/commoncap.c
index f50fc29..6bf030d 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -109,11 +109,55 @@ void cap_capset_set (struct task_struct 
 	target->cap_permitted = *permitted;
 }
 
+#define XATTR_CAPS_SUFFIX "capability"
+#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
+struct vfs_cap_data_struct {
+	__u32 version;
+	__u32 effective;
+	__u32 permitted;
+	__u32 inheritable;
+};
+
+static inline void convert_to_le(struct vfs_cap_data_struct *cap)
+{
+	cap->version = le32_to_cpu(cap->version);
+	cap->effective = le32_to_cpu(cap->effective);
+	cap->permitted = le32_to_cpu(cap->permitted);
+	cap->inheritable = le32_to_cpu(cap->inheritable);
+}
+
+static int check_cap_sanity(struct vfs_cap_data_struct *cap)
+{
+	int i;
+
+	if (cap->version != _LINUX_CAPABILITY_VERSION)
+		return -EPERM;
+
+	for (i=CAP_NUMCAPS; i<sizeof(cap->effective); i++) {
+		if (cap->effective & CAP_TO_MASK(i))
+			return -EPERM;
+	}
+	for (i=CAP_NUMCAPS; i<sizeof(cap->permitted); i++) {
+		if (cap->permitted & CAP_TO_MASK(i))
+			return -EPERM;
+	}
+	for (i=CAP_NUMCAPS; i<sizeof(cap->inheritable); i++) {
+		if (cap->inheritable & CAP_TO_MASK(i))
+			return -EPERM;
+	}
+
+	return 0;
+}
+
 int cap_bprm_set_security (struct linux_binprm *bprm)
 {
+	struct dentry *dentry;
+	ssize_t rc;
+	struct vfs_cap_data_struct cap_struct;
+	struct inode *inode;
+
 	/* Copied from fs/exec.c:prepare_binprm. */
 
-	/* We don't have VFS support for capabilities yet */
 	cap_clear (bprm->cap_inheritable);
 	cap_clear (bprm->cap_permitted);
 	cap_clear (bprm->cap_effective);
@@ -134,6 +178,45 @@ int cap_bprm_set_security (struct linux_
 		if (bprm->e_uid == 0)
 			cap_set_full (bprm->cap_effective);
 	}
+
+#ifdef CONFIG_SECURITY_FS_CAPABILITIES
+	/* Locate any VFS capabilities: */
+
+	dentry = dget(bprm->file->f_dentry);
+	inode = dentry->d_inode;
+	if (!inode->i_op || !inode->i_op->getxattr) {
+		dput(dentry);
+		return 0;
+	}
+
+	rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, &cap_struct,
+						sizeof(cap_struct));
+	dput(dentry);
+
+	if (rc == -ENODATA)
+		return 0;
+
+	if (rc < 0) {
+		printk(KERN_NOTICE "%s: Error (%d) getting xattr\n",
+				__FUNCTION__, rc);
+		return rc;
+	}
+
+	if (rc != sizeof(cap_struct)) {
+		printk(KERN_NOTICE "%s: got wrong size for getxattr (%d)\n",
+					__FUNCTION__, rc);
+		return -EPERM;
+	}
+	
+	convert_to_le(&cap_struct);
+	if (check_cap_sanity(&cap_struct))
+		return -EPERM;
+
+	bprm->cap_effective = cap_struct.effective;
+	bprm->cap_permitted = cap_struct.permitted;
+	bprm->cap_inheritable = cap_struct.inheritable;
+
+#endif
 	return 0;
 }
 
-- 
1.4.2

Re: [RFC] [PATCH] file posix capabilities

[Stephen Smalley]

On Tue, 2006-08-15 at 06:49 -0500, Serge E. Hallyn wrote:
> Quoting Nicholas Miell (nmiell@comcast.net):
> > OTOH, everybody seems to have moved from capability-based security
> > models on to TE/RBAC-based security models, so maybe this isn't worth
> > the effort?
> 
> One day perhaps, but that day isn't here yet.  People are still using
> setuid (see /sbin/passwd), so obviously they're not sufficiently
> comfortable using *only* TE/RBAC.

The hard part of capabilities isn't the kernel mechanism - it is the
proper assignment and management of the capability bits on files, and
teaching userland that uid 0 is no longer magic.  Which is all work that
is already well underway for SELinux, but you would have to replicate it
for capabilities.  And since there is no notion of equivalence classes
ala SELinux types and the "policy" is completely distributed throughout
the filesystem state, management is going to be even more painful for
the capabilities.

On the kernel side, in addition to updating the bprm_secureexec logic,
you would need to consider whether the capability module needs to
implement capability comparisons for the other hooks, like task_kill.
At present, many operations only involve uid comparisons and SELinux
checks without explicitly comparing capability sets.  Properly isolating
and protecting processes with different capability sets but the same uid
is something SELinux already can do (based on domain), whereas the
existing capability module doesn't really provide that. 
 
-- 
Stephen Smalley
National Security Agency

Re: [RFC] [PATCH] file posix capabilities

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:


> The hard part of capabilities isn't the kernel
> mechanism - it is the
> proper assignment and management of the capability
> bits on files, and
> teaching userland that uid 0 is no longer magic.

Stephen is correct here. Getting the capability
settings correct on all setuid programs is a
tough nut. Training people out of the root
model isn't easy, either.

> Which is all work that
> is already well underway for SELinux, but you would
> have to replicate it
> for capabilities.

The work underway for SELinux is different
from that of capabilities. POSIX capabilities
offer substantial benefits without the high
cost of SELinux.

> And since there is no notion of
> equivalence classes
> ala SELinux types and the "policy" is completely
> distributed throughout
> the filesystem state, management is going to be even
> more painful for
> the capabilities.

This is not the experiance of Irix, which
has supported POSIX capabilities for years.

> On the kernel side, in addition to updating the
> bprm_secureexec logic,
> you would need to consider whether the capability
> module needs to
> implement capability comparisons for the other
> hooks, like task_kill.
> At present, many operations only involve uid
> comparisons and SELinux
> checks without explicitly comparing capability sets.

Yes. There is work to be done.

>  Properly isolating
> and protecting processes with different capability
> sets but the same uid
> is something SELinux already can do (based on
> domain), whereas the
> existing capability module doesn't really provide
> that. 

That's a matter of taste in policy. There
is certainly no Common Criteria requirement
for that.

Sure, SELinux and POSIX capabilities are
different. No arguement. POSIX capabilities
predate SELinux in the community and in the
Linux kernel. To date they have been limited
by the lack of xattr support, but now that 
that is available there is every reason to
complete the implementation.


Casey Schaufler
casey@schaufler-ca.com

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Tue, 2006-08-15 at 06:49 -0500, Serge E. Hallyn wrote:
> > Quoting Nicholas Miell (nmiell@comcast.net):
> > > OTOH, everybody seems to have moved from capability-based security
> > > models on to TE/RBAC-based security models, so maybe this isn't worth
> > > the effort?
> > 
> > One day perhaps, but that day isn't here yet.  People are still using
> > setuid (see /sbin/passwd), so obviously they're not sufficiently
> > comfortable using *only* TE/RBAC.
> 
> The hard part of capabilities isn't the kernel mechanism - it is the

I didn't claim to be doing the hard part  :)

> proper assignment and management of the capability bits on files, and
> teaching userland that uid 0 is no longer magic.

Of course setuid still works, so it doesn't need to be done all at once.

> Which is all work that
> is already well underway for SELinux, but you would have to replicate it
> for capabilities.  And since there is no notion of equivalence classes
> ala SELinux types and the "policy" is completely distributed throughout
> the filesystem state, management is going to be even more painful for
> the capabilities.

But since file capabilities cannot survive an exec, analysis with a gui
which walks the fs could be pretty simple.

> On the kernel side, in addition to updating the bprm_secureexec logic,
> you would need to consider whether the capability module needs to
> implement capability comparisons for the other hooks, like task_kill.
> At present, many operations only involve uid comparisons and SELinux
> checks without explicitly comparing capability sets.  Properly isolating
> and protecting processes with different capability sets but the same uid
> is something SELinux already can do (based on domain), whereas the
> existing capability module doesn't really provide that. 

Very good point.  Preventing communication channels i.e. through signals
isn't a concern, but user hallyn ptracing himself running /bin/passwd
certainly is.

Thanks.

-serge

Re: [RFC] [PATCH] file posix capabilities

[Stephen Smalley]

On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > On Tue, 2006-08-15 at 06:49 -0500, Serge E. Hallyn wrote:
> > > Quoting Nicholas Miell (nmiell@comcast.net):
> > > > OTOH, everybody seems to have moved from capability-based security
> > > > models on to TE/RBAC-based security models, so maybe this isn't worth
> > > > the effort?
> > > 
> > > One day perhaps, but that day isn't here yet.  People are still using
> > > setuid (see /sbin/passwd), so obviously they're not sufficiently
> > > comfortable using *only* TE/RBAC.
> > 
> > The hard part of capabilities isn't the kernel mechanism - it is the
> 
> I didn't claim to be doing the hard part  :)

Yes, but the question is whether anyone will do the hard part.  And
whether it is worth doing.  And whether you make the system unsafe along
the way, particularly given the permissive nature of capabilities.

> But since file capabilities cannot survive an exec, analysis with a gui
> which walks the fs could be pretty simple.

Except that people actually want them to be inheritable (under certain
conditions), just in a way that avoids the problems encountered in the
past.  If you start on the path of making capabilities useful, you'll
have to tackle that as well.

> > On the kernel side, in addition to updating the bprm_secureexec logic,
> > you would need to consider whether the capability module needs to
> > implement capability comparisons for the other hooks, like task_kill.
> > At present, many operations only involve uid comparisons and SELinux
> > checks without explicitly comparing capability sets.  Properly isolating
> > and protecting processes with different capability sets but the same uid
> > is something SELinux already can do (based on domain), whereas the
> > existing capability module doesn't really provide that. 
> 
> Very good point.  Preventing communication channels i.e. through signals
> isn't a concern, but user hallyn ptracing himself running /bin/passwd
> certainly is.

Actually, ptrace already performs a capability comparison (cap_ptrace).
Wrt signals, it wasn't the communication channel that concerned me but
the ability to interfere with the operation of a process running in the
same uid but different capabilities, like stopping it at a critical
point.  Likewise with many other task hooks - you wouldn't want to be
able to depress the priority of a process running with greater
capabilities.

One other point to consider is Solaris seems to have diverged from their
own past approaches for privileges/capabilities,
http://blogs.sun.com/casper/20040722
http://www.opensolaris.org/os/community/security/library/howto/privbracket/

Doesn't sound like they are even using file capabilities at all.

Also, think about the real benefits of capabilities, at least as defined
in Linux.  The coarse granularity and the lack of any per-object support
is a fairly significant deficiency there that is much better handled via
TE.  At least some of the Linux capabilities lend themselves to easy
privilege escalation to gaining other capabilities or effectively
bypassing them.

-- 
Stephen Smalley
National Security Agency

Re: [RFC] [PATCH] file posix capabilities

[Joshua Brindle]

Stephen Smalley wrote:
> On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
>   
> <snip>
>> Very good point.  Preventing communication channels i.e. through signals
>> isn't a concern, but user hallyn ptracing himself running /bin/passwd
>> certainly is.
>>     
>
> Actually, ptrace already performs a capability comparison (cap_ptrace).
> Wrt signals, it wasn't the communication channel that concerned me but
> the ability to interfere with the operation of a process running in the
> same uid but different capabilities, like stopping it at a critical
> point.  Likewise with many other task hooks - you wouldn't want to be
> able to depress the priority of a process running with greater
> capabilities.
>
>   
On this point, what about environment tampering of processes with caps? 
LD_PRELOAD=my_bad_lib.so /usr/bin/passwd. glibc atsecure logic would 
have to be updated to do a capability comparison.

> One other point to consider is Solaris seems to have diverged from their
> own past approaches for privileges/capabilities,
> http://blogs.sun.com/casper/20040722
> http://www.opensolaris.org/os/community/security/library/howto/privbracket/
>
> Doesn't sound like they are even using file capabilities at all.
>
> Also, think about the real benefits of capabilities, at least as defined
> in Linux.  The coarse granularity and the lack of any per-object support
> is a fairly significant deficiency there that is much better handled via
> TE.  At least some of the Linux capabilities lend themselves to easy
> privilege escalation to gaining other capabilities or effectively
> bypassing them

Re: [RFC] [PATCH] file posix capabilities

[Stephen Smalley]

On Thu, 2006-08-17 at 08:00 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
> >   
> > <snip>
> >> Very good point.  Preventing communication channels i.e. through signals
> >> isn't a concern, but user hallyn ptracing himself running /bin/passwd
> >> certainly is.
> >>     
> >
> > Actually, ptrace already performs a capability comparison (cap_ptrace).
> > Wrt signals, it wasn't the communication channel that concerned me but
> > the ability to interfere with the operation of a process running in the
> > same uid but different capabilities, like stopping it at a critical
> > point.  Likewise with many other task hooks - you wouldn't want to be
> > able to depress the priority of a process running with greater
> > capabilities.
> >
> >   
> On this point, what about environment tampering of processes with caps? 
> LD_PRELOAD=my_bad_lib.so /usr/bin/passwd. glibc atsecure logic would 
> have to be updated to do a capability comparison.

That's the bprm_secureexec logic change that has already been mentioned;
that determines the AT_SECURE value, and glibc then just acts based on
that value provided by the kernel.  Just a matter of extending
cap_bprm_secureexec to compare the capability sets.  Already on Serge's
todo list, but it is necessary for this to be a safe change, and should
happen before this patch goes anywhere (even -mm), IMHO.

-- 
Stephen Smalley
National Security Agency

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Thu, 2006-08-17 at 08:00 -0400, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
> > >   
> > > <snip>
> > >> Very good point.  Preventing communication channels i.e. through signals
> > >> isn't a concern, but user hallyn ptracing himself running /bin/passwd
> > >> certainly is.
> > >>     
> > >
> > > Actually, ptrace already performs a capability comparison (cap_ptrace).
> > > Wrt signals, it wasn't the communication channel that concerned me but
> > > the ability to interfere with the operation of a process running in the
> > > same uid but different capabilities, like stopping it at a critical
> > > point.  Likewise with many other task hooks - you wouldn't want to be
> > > able to depress the priority of a process running with greater
> > > capabilities.
> > >
> > >   
> > On this point, what about environment tampering of processes with caps? 
> > LD_PRELOAD=my_bad_lib.so /usr/bin/passwd. glibc atsecure logic would 
> > have to be updated to do a capability comparison.
> 
> That's the bprm_secureexec logic change that has already been mentioned;
> that determines the AT_SECURE value, and glibc then just acts based on
> that value provided by the kernel.  Just a matter of extending
> cap_bprm_secureexec to compare the capability sets.  Already on Serge's
> todo list, but it is necessary for this to be a safe change, and should
> happen before this patch goes anywhere (even -mm), IMHO.

Does the following seem a reasonable way to handle secureexec in the
face of file caps?

Seems like it should work so long as we don't have to worry about the
bprm changing partway through exec.  This should avoid the need to store
the old capabilities.

Unless I've got my head screwed on completely backward...

thanks,
-serge

(note - Still need at least a signals patch on top of this before the
file caps could be safe for use)

>From e791e196cda84743e805167c11e424f4132aa2a4 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Mon, 21 Aug 2006 14:54:17 -0500
Subject: [PATCH 1/1] security: handle secureexec with filesystem capabilities

A secure exec is required if euid!=uid, and, correspondingly,
if the executable's file capability set was not empty and the
process is not owned by (real uid) root.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
 security/commoncap.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 6bf030d..b1777a9 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -265,11 +265,15 @@ void cap_bprm_apply_creds (struct linux_
 
 int cap_bprm_secureexec (struct linux_binprm *bprm)
 {
-	/* If/when this module is enhanced to incorporate capability
-	   bits on files, the test below should be extended to also perform a 
-	   test between the old and new capability sets.  For now,
-	   it simply preserves the legacy decision algorithm used by
-	   the old userland. */
+	if (current->uid != 0) {
+		if (!cap_isclear(bprm->cap_effective))
+			return 1;
+		if (!cap_isclear(bprm->cap_permitted))
+			return 1;
+		if (!cap_isclear(bprm->cap_inheritable))
+			return 1;
+	}
+
 	return (current->euid != current->uid ||
 		current->egid != current->gid);
 }
-- 
1.4.2

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

The following patch addresses remaining LSM hooks which need to be
handled in the face of file capabilities.  This is on top of the
cap_bprm_secureexec patch in the email I had replied to.

-serge

>From 7ee4dafddb85d6ccf34ddc50e2a44b244bb4b6b3 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Mon, 28 Aug 2006 14:39:57 -0500
Subject: [PATCH 3/3] fscaps: define task_kill and other new capchecks

task_setrlimit, task_prctl, and task_movememory are not a problem
with fscaps.  This patch defines task_setscheduler, task_setioprio,
cap_task_kill, and task_setnice to make sure a user cannot affect a
process in which they called a program with some fscaps.

One remaining question is the note under task_setscheduler: are we
ok with CAP_SYS_NICE being sufficient to confine a process to a
cpuset?

It is a semantic change, as without fsccaps, attach_task doesn't
allow CAP_SYS_NICE to override the uid equivalence check.  But since
it uses security_task_setscheduler, which elsewhere is used where
CAP_SYS_NICE can be used to override the uid equivalence check,
fixing it might be tough.

     task_setscheduler
         need to check for !capable(CAP_SYS_NICE)  && current->euid==p->euid
             && !cap_subset(current->caps, p->caps) where p->caps are not
             subset of current->caps
         note: this also controls cpuset:attach_task.  Are we ok with
             CAP_SYS_NICE being used to confine to a cpuset?
     task_setioprio
         Same check as task_setscheduler
     task_setnice
         sys_setpriority uses this (through set_one_prio) for another
         process.  Need same checks as setrlimit

 no need:
     task_setrlimit
         affect only calling task
     task_prctl (set_dumpable, set_keepcaps)
         affect only calling task
     task_movememory
         CAP_SYS_NICE is already checked

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
 include/linux/security.h |   10 +++++--
 security/capability.c    |    4 +++
 security/commoncap.c     |   62 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 73 insertions(+), 3 deletions(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index f753038..7a99930 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -51,6 +51,10 @@ extern int cap_inode_setxattr(struct den
 extern int cap_inode_removexattr(struct dentry *dentry, char *name);
 extern int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid, int flags);
 extern void cap_task_reparent_to_init (struct task_struct *p);
+extern int cap_task_kill(struct task_struct *p, struct siginfo *info, int sig, u32 secid);
+extern int cap_task_setscheduler (struct task_struct *p, int policy, struct sched_param *lp);
+extern int cap_task_setioprio (struct task_struct *p, int ioprio);
+extern int cap_task_setnice (struct task_struct *p, int nice);
 extern int cap_syslog (int type);
 extern int cap_vm_enough_memory (long pages);
 
@@ -2522,12 +2526,12 @@ static inline int security_task_setgroup
 
 static inline int security_task_setnice (struct task_struct *p, int nice)
 {
-	return 0;
+	return cap_task_setnice(p, nice);
 }
 
 static inline int security_task_setioprio (struct task_struct *p, int ioprio)
 {
-	return 0;
+	return cap_task_setioprio(p, ioprio);
 }
 
 static inline int security_task_getioprio (struct task_struct *p)
@@ -2562,7 +2566,7 @@ static inline int security_task_kill (st
 				      struct siginfo *info, int sig,
 				      u32 secid)
 {
-	return 0;
+	return cap_task_kill(p, info, sig, secid);
 }
 
 static inline int security_task_wait (struct task_struct *p)
diff --git a/security/capability.c b/security/capability.c
index b868e7e..14cb592 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -40,6 +40,10 @@ static struct security_operations capabi
 	.inode_setxattr =		cap_inode_setxattr,
 	.inode_removexattr =		cap_inode_removexattr,
 
+	.task_kill =			cap_task_kill,
+	.task_setscheduler =		cap_task_setscheduler,
+	.task_setioprio =		cap_task_setioprio,
+	.task_setnice =			cap_task_setnice,
 	.task_post_setuid =		cap_task_post_setuid,
 	.task_reparent_to_init =	cap_task_reparent_to_init,
 
diff --git a/security/commoncap.c b/security/commoncap.c
index b1777a9..82bd59f 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -387,6 +387,64 @@ int cap_task_post_setuid (uid_t old_ruid
 	return 0;
 }
 
+/*
+ * Rationale: code calling task_setscheduler, task_setioprio, and
+ * task_setnice, assumes that
+ *   . if capable(cap_sys_nice), then those actions should be allowed
+ *   . if not capable(cap_sys_nice), but acting on your own processes,
+ *   	then those actions should be allowed
+ * This is insufficient now since you can call code without suid, but
+ * yet with increased caps.
+ * So we check for increased caps on the target process.
+ */
+static inline int cap_safe_nice(struct task_struct *p)
+{
+	if (!cap_issubset(p->cap_permitted, current->cap_permitted) &&
+	    !__capable(current, CAP_SYS_NICE))
+		return -EPERM;
+	return 0;
+}
+
+int cap_task_setscheduler (struct task_struct *p, int policy,
+			   struct sched_param *lp)
+{
+	return cap_safe_nice(p);
+}
+
+int cap_task_setioprio (struct task_struct *p, int ioprio)
+{
+	return cap_safe_nice(p);
+}
+
+int cap_task_setnice (struct task_struct *p, int nice)
+{
+	return cap_safe_nice(p);
+}
+
+int cap_task_kill(struct task_struct *p, struct siginfo *info,
+				int sig, u32 secid)
+{
+	if (info != SEND_SIG_NOINFO && (is_si_special(info) || SI_FROMKERNEL(info)))
+		return 0;
+
+	if (secid)
+		/*
+		 * Signal sent as a particular user.
+		 * Capabilities are ignored.  May be wrong, but it's the
+		 * only thing we can do at the moment.
+		 * Used only by usb drivers?
+		 */
+		return 0;
+	if (current->uid == 0 || current->euid == 0)
+		return 0;
+	if (capable(CAP_KILL))
+		return 0;
+	if (cap_issubset(p->cap_permitted, current->cap_permitted))
+		return 0;
+
+	return -EPERM;
+}
+
 void cap_task_reparent_to_init (struct task_struct *p)
 {
 	p->cap_effective = CAP_INIT_EFF_SET;
@@ -424,6 +482,10 @@ EXPORT_SYMBOL(cap_bprm_secureexec);
 EXPORT_SYMBOL(cap_inode_setxattr);
 EXPORT_SYMBOL(cap_inode_removexattr);
 EXPORT_SYMBOL(cap_task_post_setuid);
+EXPORT_SYMBOL(cap_task_kill);
+EXPORT_SYMBOL(cap_task_setscheduler);
+EXPORT_SYMBOL(cap_task_setioprio);
+EXPORT_SYMBOL(cap_task_setnice);
 EXPORT_SYMBOL(cap_task_reparent_to_init);
 EXPORT_SYMBOL(cap_syslog);
 EXPORT_SYMBOL(cap_vm_enough_memory);
-- 
1.4.2

Re: [RFC] [PATCH] file posix capabilities

[Seth Arnold]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

On Mon, Aug 28, 2006 at 04:39:12PM -0500, Serge E. Hallyn wrote:
> +int cap_task_kill(struct task_struct *p, struct siginfo *info,
> +				int sig, u32 secid)
> +{
> +	if (info != SEND_SIG_NOINFO && (is_si_special(info) || SI_FROMKERNEL(info)))
> +		return 0;
> +
> +	if (secid)
> +		/*
> +		 * Signal sent as a particular user.
> +		 * Capabilities are ignored.  May be wrong, but it's the
> +		 * only thing we can do at the moment.
> +		 * Used only by usb drivers?
> +		 */
> +		return 0;
> +	if (current->uid == 0 || current->euid == 0)
> +		return 0;

uid/euid checks feel out of place in the capabilities code.

> +	if (capable(CAP_KILL))
> +		return 0;
> +	if (cap_issubset(p->cap_permitted, current->cap_permitted))
> +		return 0;
> +
> +	return -EPERM;
> +}

Thanks Serge

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Seth Arnold (seth.arnold@suse.de):
> On Mon, Aug 28, 2006 at 04:39:12PM -0500, Serge E. Hallyn wrote:
> > +int cap_task_kill(struct task_struct *p, struct siginfo *info,
> > +				int sig, u32 secid)
> > +{
> > +	if (info != SEND_SIG_NOINFO && (is_si_special(info) || SI_FROMKERNEL(info)))
> > +		return 0;
> > +
> > +	if (secid)
> > +		/*
> > +		 * Signal sent as a particular user.
> > +		 * Capabilities are ignored.  May be wrong, but it's the
> > +		 * only thing we can do at the moment.
> > +		 * Used only by usb drivers?
> > +		 */
> > +		return 0;
> > +	if (current->uid == 0 || current->euid == 0)
> > +		return 0;
> 
> uid/euid checks feel out of place in the capabilities code.

Wow, good point.

Will fix.

thanks,
-serge

Re: [RFC] [PATCH] file posix capabilities

[Crispin Cowan]

Stephen Smalley wrote:
> On Tue, 2006-08-15 at 21:42 -0500, Serge E. Hallyn wrote:
>   
>> But since file capabilities cannot survive an exec, analysis with a gui
>> which walks the fs could be pretty simple.
>>     
> Except that people actually want them to be inheritable (under certain
> conditions), just in a way that avoids the problems encountered in the
> past.  If you start on the path of making capabilities useful, you'll
> have to tackle that as well.
>   
Stephen makes a good point here.

Have you looked at how AppArmor handles POSIX Capabilities? It has these
advantages:

    * Whether a capability is inheritable or not is specified by policy,
      addressing Stephan's' point.
    * Does not depend on extended attributes, so becomes filesystem
      independent.
    * As I understand it, it resembles the Solaris "process rights"
      mechanism, and so (as Albert Cahalan suggested) will be less
      surprising to Solaris users transitioning to Linux.

Currently it is implemented as part of the AppArmor module, but I could
imagine it being busted out into a separate module. The main thing I
would wonder about is some kind of API so that policy engines like
AppArmor and SELinux could manipulate the POSIX capabilities.

> Actually, ptrace already performs a capability comparison (cap_ptrace).
> Wrt signals, it wasn't the communication channel that concerned me but
> the ability to interfere with the operation of a process running in the
> same uid but different capabilities, like stopping it at a critical
> point.  Likewise with many other task hooks - you wouldn't want to be
> able to depress the priority of a process running with greater
> capabilities.
>   
Is that a property of Serge's module? Or just a property of the basic
crappyness of the POSIX Capabilities idea in the first place?

> Also, think about the real benefits of capabilities, at least as defined
> in Linux.  The coarse granularity and the lack of any per-object support
> is a fairly significant deficiency there that is much better handled via
> TE.
Only if the user wants to buy all the way into TE. Making POSIX
Capabilities, TE, and AppArmor composeable choices seems like a good
goal. The question is whether POSIX Capabilities on their own are worth
while. But consider:

    * They are already there on their own, pulling POSIX Capabilities
      out seems like a non-option because too much already uses them.
    * They are nearly useless without some kind of management interface.
      Adding a decent management interface can only make it better.

Serge has proposed a reasonable model. I would like to suggest that
people, especially Serge, consider the AppArmor model as well before
deciding.

To quickly summarize the AppArmor model, you have an external policy
file that says that e.g. /usr/local/foo can have net_bind_service and
ipc_lock. This is a bit mask overlaid on top of whatever capabilities
the process already has, e.g. because it is UID 0 it has all of them. So
if someone runs /usr/local/foo as an unprivileged user, it has no
capabilities, and the bitmask does nothing. If someone runs
/usr/local/foo as root, then instead of all 32 capabilities, they get
only those 2.

>  At least some of the Linux capabilities lend themselves to easy
> privilege escalation to gaining other capabilities or effectively
> bypassing them.
>   
Certainly; cap_sys_admin effectively gives you ownership of the machine.
But that is fundamental to the POSIX Capabilities model, and not
something that Serge can change.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes

Re: [RFC] [PATCH] file posix capabilities

[Casey Schaufler]

--- Crispin Cowan <crispin@novell.com> wrote:

> >  At least some of the Linux capabilities lend
> themselves to easy
> > privilege escalation to gaining other capabilities
> or effectively
> > bypassing them.
> >   
> Certainly; cap_sys_admin effectively gives you
> ownership of the machine.
> But that is fundamental to the POSIX Capabilities
> model, and not
> something that Serge can change.

In turn it is fundamental to the curious
granularity of privileged operations in Unix.

I maintain that the real value in the POSIX
capability model derives from seperating the
permission to violate policy from the UID.

Granularity of such privilege is a bonus, and
a matter of considerable debate. DGUX ended
up with over 330 distinct capabilities, while
Irix had (last I looked) 24, and Solaris
came in somewhere between. All these systems
work.


Casey Schaufler
casey@schaufler-ca.com

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Crispin Cowan (crispin@novell.com):
> Stephen Smalley wrote:
> > Also, think about the real benefits of capabilities, at least as defined
> > in Linux.  The coarse granularity and the lack of any per-object support
> > is a fairly significant deficiency there that is much better handled via
> > TE.
> Only if the user wants to buy all the way into TE. Making POSIX
> Capabilities, TE, and AppArmor composeable choices seems like a good
> goal. The question is whether POSIX Capabilities on their own are worth
> while. But consider:
> 
>     * They are already there on their own, pulling POSIX Capabilities
>       out seems like a non-option because too much already uses them.
>     * They are nearly useless without some kind of management interface.
>       Adding a decent management interface can only make it better.
> 
> Serge has proposed a reasonable model. I would like to suggest that
> people, especially Serge, consider the AppArmor model as well before
> deciding.

So far this is not deciding on anything, just trying to follow the
partially implemented draft to it's specified and logical conclusion.
It may well be that it will turn out to just not be manageable, safe, or
useful, or none of the three.

> To quickly summarize the AppArmor model, you have an external policy

Does this stack with the capability module, or do you use purely your
own logic?

> file that says that e.g. /usr/local/foo can have net_bind_service and
> ipc_lock. This is a bit mask overlaid on top of whatever capabilities
> the process already has, e.g. because it is UID 0 it has all of them. So
> if someone runs /usr/local/foo as an unprivileged user, it has no
> capabilities, and the bitmask does nothing. If someone runs
> /usr/local/foo as root, then instead of all 32 capabilities, they get
> only those 2.

Can't do that with the fs capabilities.

But, the fs caps aren't intended to be an alternative to a policy-basd
system.  What I like about them is simply that instead of making a
binary setuid 0, and expecting it to give up the caps it doesn't need,
it can be given just the caps it needs right off the bat.

The apparmor and selinux policies would be complementary and useful as
ever on top of those, just as they currently are on top of setuid.

> >  At least some of the Linux capabilities lend themselves to easy
> > privilege escalation to gaining other capabilities or effectively
> > bypassing them.
> >   
> Certainly; cap_sys_admin effectively gives you ownership of the machine.
> But that is fundamental to the POSIX Capabilities model, and not
> something that Serge can change.

Yup, sigh...

A better split of the caps might be more useful than fs caps
themselves...

-serge

Re: [RFC] [PATCH] file posix capabilities

[Seth Arnold]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Mon, Aug 21, 2006 at 09:50:36PM -0500, Serge E. Hallyn wrote:
> > To quickly summarize the AppArmor model, you have an external policy
> 
> Does this stack with the capability module, or do you use purely your
> own logic?

We link against the commoncap facility introduced by Bert Hubert, to
provide 'standard' capabilities support; we simply add another check at
capable() time to _also_ check the capability against the list allowed
in the current profile.

> But, the fs caps aren't intended to be an alternative to a policy-basd
> system.  What I like about them is simply that instead of making a
> binary setuid 0, and expecting it to give up the caps it doesn't need,
> it can be given just the caps it needs right off the bat.
> 
> The apparmor and selinux policies would be complementary and useful as
> ever on top of those, just as they currently are on top of setuid.

Seems like a great idea for e.g. binding to low ports, chroot, and
changing users for e.g. password changing. The other 24-26 capabilities
may be less useful. :) Still, I agree, complementary, and hopefully a
mechanism such as this proposed mechanism would help drag capabilities
out of the dark ages.

Thanks Serge

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] [PATCH] file posix capabilities

[Crispin Cowan]

Nicholas Miell wrote:
> OTOH, everybody seems to have moved from capability-based security
> models on to TE/RBAC-based security models, so maybe this isn't worth
> the effort?
>   
TE, RBAC, AppArmor, and POSIX.1e Capabilities are all capability-based
systems, in that they all store the security attributes in the principal
(process, program, whatever) rather than the object (the files being
accessed). The difference is in the style of specifying the principals
and objects.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes

Re: [RFC] [PATCH] file posix capabilities

[KaiGai Kohei]

Hi,

>> See
>> http://www.kaigai.gr.jp/index.php?FrontPage#b556e50d
>> http://www.kaigai.gr.jp/pub/fscaps-1.0-kg.src.rpm
>>
>> The later SRPM package includes the cap_file.c.
>> It will be a good sample of using libcaps.
> 
> And this has a version number built in, as Eric was asking for.

_LINUX_CAPABILITY_VERSION defined as 0x19980330 is used for this.
Is there a possibility to be changed future, isn't it?
For example, when we think 32-bit width is not enough.

> My tools were purely for testing, and just kept everything as simple as
> possible.  So I'll happily port the kernel patch to use your tools  :)
> 
> For that matter I see you have your own kernel patch.  Would you mind
> submitting that to lkml as an alternative to mine?

I have no plan to submit now. It'll be called "Re-investment of wheel".
# In addition, I'm currently busy to hack PostgreSQL. :D

I hope to confirm one more point.
Endian conpatibility is considered in the patches?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting KaiGai Kohei (kaigai.kohei@gmail.com):
> Hi,
> 
> >>See
> >>http://www.kaigai.gr.jp/index.php?FrontPage#b556e50d
> >>http://www.kaigai.gr.jp/pub/fscaps-1.0-kg.src.rpm
> >>
> >>The later SRPM package includes the cap_file.c.
> >>It will be a good sample of using libcaps.
> >
> >And this has a version number built in, as Eric was asking for.
> 
> _LINUX_CAPABILITY_VERSION defined as 0x19980330 is used for this.
> Is there a possibility to be changed future, isn't it?
> For example, when we think 32-bit width is not enough.
> 
> >My tools were purely for testing, and just kept everything as simple as
> >possible.  So I'll happily port the kernel patch to use your tools  :)
> >
> >For that matter I see you have your own kernel patch.  Would you mind
> >submitting that to lkml as an alternative to mine?
> 
> I have no plan to submit now. It'll be called "Re-investment of wheel".

Assuming you meant reinvention, not at all.  We want to get the best
patch in.

> # In addition, I'm currently busy to hack PostgreSQL. :D

Ok, well thanks for taking a look at this one.

> I hope to confirm one more point.
> Endian conpatibility is considered in the patches?

Not yet.  Will add that and a check of the cap bitfield length as
mentioned in another email.

thanks,
-serge

Re: [RFC] [PATCH] file posix capabilities

[Casey Schaufler]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]



--- "Serge E. Hallyn" <serue@us.ibm.com> wrote:


> +
> +	bprm->cap_effective = fscaps[0];
> +	bprm->cap_inheritable = fscaps[1];
> +	bprm->cap_permitted = fscaps[2];
> +

It does not appear that you're attempting
to maintain the POSIX exec semantics for
capability sets. (If you're doing it
elsewhere in the code, nevermind) I don't
know if this is intentional or not.
I will have a closer look, but just for
grins, I've attached code from the SGI
OB1 offering of some years back that
includes a function, cap_recalc, that
implements the correct behavior. I will
also take a stab at working it in, but
I expect someone will beat me to it.


Casey Schaufler
casey@schaufler-ca.com

[-- Attachment #2: 1104682580-capability.c --]
[-- Type: text/plain, Size: 10748 bytes --]

/*
 * 
 * Copyright 1990 Silicon Graphics, Inc. 
 * All rights reserved.
 *     
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 */
#ident	"$SGIRevision: 1.30 $"

#include "sys/types.h"
#include "sys/systm.h"
#include "sys/debug.h"
#include "sys/cmn_err.h"
#include "ksys/cred.h"
#include "sys/proc.h"
#include "sys/vfs.h"
#include "sys/param.h"
#include "sys/errno.h"
#include "sys/vfs.h"
#include "sys/vnode.h"
#include "sys/fstyp.h"
#include "ksys/vfile.h"
#include "ksys/fdt.h"
#include "sys/uio.h"
#include "sys/pathname.h"
#include "sys/capability.h"
#include "sys/sat.h"
#include "sys/attributes.h"
#include "os/proc/pproc_private.h"	/* XXX bogus */
#include "ksys/fdt.h"
#include "sys/uthread.h"

/*
 * Make the default be augmented superuser.
 */
void
cap_init()
{
	cap_enabled = CAP_SYS_SUPERUSER;
}

/*
 * Give the requested credential all privileges.
 * This is used to initialize sys_cred and NFS server credentials.
 */
void
cap_empower_cred(cred_t *cr)
{
	cr->cr_cap.cap_effective = CAP_ALL_ON;
	cr->cr_cap.cap_inheritable = CAP_ALL_ON;
	cr->cr_cap.cap_permitted = CAP_ALL_ON;
}

int
cap_vtocap(vnode_t *vp, cap_t capp)
{
	int error;
	int i = sizeof(cap_set_t);

	VOP_ATTR_GET(vp, SGI_CAP_FILE, (char *)capp, &i, ATTR_ROOT,
	    sys_cred, error);

	return error;
}

/*
 * Recalculate the process capabilities appropriate after exec(2).  Uses the
 * POSIX P1003.1eD16 algorythm.  For exec()'s of SCAP files:
 *
 *     New-inheritable = Proc-inheritable & File-inheritable
 *     New-permitted   = (New-inheritable & Proc-permitted) | File-permitted
 *     New-effective   = File-effective & New-permitted
 *
 * For exec()'s of non-SCAP files when the current cap_inheritable has
 * CAP_FLAG_PURE_RECALC set we drop all capabilities.  Otherwise we leave
 * the process' current capabilities alone.
 *
 * Called with proposed new capabilities from file, "fcap" (which will be
 * invalid if the file doesn't have any attached capabilities).  Returns with
 * recalculated capabilities in *current* process credentials.  Also returns
 * whether or not the calculation resulted in an increase in capabilities.
 * Must be called with pcred_lock() set.
 */
int
cap_recalc(const cap_set_t *fcap)
{
	uthread_t *ut = curuthread;
	proc_t *p = UT_TO_PROC(ut);	/* XXX virtualize this? */
	cred_t *cr = p->p_cred;
	cap_set_t *pcap = &cr->cr_cap;
	int rxev;

	/*
	 * This routine is called only from exec, so there's only one
	 * uthread, and we don't have to pcred_push() the changes to the
	 * uthread.  Also assert that we have the credentials lock ...
	 */
	ASSERT(!(ut->ut_flags & UT_PTHREAD));
	ASSERT(pcred_islocked(p));

	if (fcap->cap_effective & CAP_INVALID) {
		/*
		 * File didn't have any capabilities attached to it.  If
		 * CAP_FLAG_PURE_RECALC is set clear any capabilities.
		 * Otherwise, leave everything alone and return.  Note: We
		 * oughtn't need to retain the CAP_FLAG_PURE_RECALC flag.
		 */
		if (pcap->cap_inheritable & CAP_FLAG_PURE_RECALC) {
			#pragma mips_frequency_hint NEVER
			pcap->cap_effective   = CAP_ALL_OFF;
			pcap->cap_permitted   = CAP_ALL_OFF;
			pcap->cap_inheritable = CAP_FLAG_PURE_RECALC;
		}
		rxev = 0;
	} else {
		#pragma mips_frequency_hint NEVER
		cap_set_t opcap = *pcap;

		pcap->cap_inheritable = CAP_ALL_ON & 
			(pcap->cap_inheritable & fcap->cap_inheritable);
		pcap->cap_permitted = CAP_ALL_ON & 
			((pcap->cap_inheritable & pcap->cap_permitted) |
			 fcap->cap_permitted);
		pcap->cap_effective = CAP_ALL_ON &
			(fcap->cap_effective & pcap->cap_permitted);

		rxev = ((pcap->cap_effective   & ~opcap.cap_effective) ||
			(pcap->cap_permitted   & ~opcap.cap_permitted) ||
			(pcap->cap_inheritable & ~opcap.cap_inheritable));
	}

	if ((pcap->cap_effective & CAP_ALL_ON) ||
	    (pcap->cap_permitted & CAP_ALL_ON))
		p_flagset(p, SPRPROTECT);
	else
		p_flagclr(p, SPRPROTECT);

	return rxev;
}

int
cap_setpcap(cap_set_t *src, cap_value_t *flags)
{
	struct cred *cr;
	/* REFERENCED */
	proc_t *pp = curprocp;

	if (flags != NULL) {
		ASSERT(src == NULL);
		cr = pcred_lock(pp);
		cr = crcopy(pp);
		cr->cr_cap.cap_inheritable =
		    (cr->cr_cap.cap_inheritable & CAP_ALL_ON) |
		    (*flags & CAP_FLAGS);
		pcred_push(pp);
		return 0;
	}

	ASSERT(src != NULL);

	if ((src->cap_inheritable & CAP_INVALID) ||
	    (src->cap_permitted & CAP_INVALID) ||
	    (src->cap_effective & CAP_INVALID))
		return EINVAL;

	/*
	 * Clear any flag bits in the new set.
	 */
	src->cap_inheritable &= CAP_ALL_ON;
	src->cap_permitted &= CAP_ALL_ON;
	src->cap_effective &= CAP_ALL_ON;

	/*
	 * Audit the old capability set
	 */
	_SAT_SAVE_ATTR(SAT_CAP_SET_TOKEN, curuthread);

	cr = pcred_lock(pp);

	if ((!CAP_ID_ISSET(src->cap_inheritable,
			   cr->cr_cap.cap_inheritable) &&
	     !CAP_ID_ISSET(src->cap_inheritable,
			   cr->cr_cap.cap_permitted)) ||
	    (!CAP_ID_ISSET(src->cap_permitted, cr->cr_cap.cap_permitted)) ||
	    (!CAP_ID_ISSET(src->cap_effective, cr->cr_cap.cap_effective) &&
	     !CAP_ID_ISSET(src->cap_effective, cr->cr_cap.cap_permitted))) {
		if (!cap_able(CAP_SETPPRIV)) {
			pcred_push(pp);
			_SAT_SETPCAP(src, EPERM);
			return EPERM;
		}
	}

	/*
	 * Retain the flags stored in the inheritable set.
	 */
	src->cap_inheritable |= cr->cr_cap.cap_inheritable & CAP_FLAGS;

	/*
	 * At this point we are going to set the requested capability state
	 * so, check whether the process will have any permitted or effective
	 * capabilities after the call is over.  If so, taint the process
	 * so that access through /proc is privileged from now on (until
	 * the next exec())
	 */
	if (   (src->cap_permitted & CAP_ALL_ON)
	    || (src->cap_effective & CAP_ALL_ON)) {
		p_flagset(pp, SPRPROTECT);
	}

	/*
	 * Set the requested capability state.
	 */
	cr = crcopy(pp);
	cr->cr_cap = *src;
	pcred_push(pp);

	_SAT_SETPCAP(src, 0);
	return 0;
}

int
cap_request(cap_value_t cid)
{
	proc_t *pp = curprocp;
	struct cred *cr = pcred_lock(pp);

	if (CAP_ID_ISSET(cid, cr->cr_cap.cap_permitted)) {
		if (!CAP_ID_ISSET(cid, cr->cr_cap.cap_effective)) {
			cr = crcopy(pp);
			CAP_ID_SET(cid, cr->cr_cap.cap_effective);
			pcred_push(pp);
		} else
			pcred_unlock(pp);
		return 0;
	}
	pcred_unlock(pp);
	return EPERM;
}


int
cap_surrender(cap_value_t cid)
{
	proc_t *pp = curprocp;
	struct cred *cr = pcred_lock(pp);

	if (CAP_ID_ISSET(cid, cr->cr_cap.cap_effective)) {
		cr = crcopy(pp);
		CAP_ID_CLEAR(cid, cr->cr_cap.cap_effective);
		pcred_push(pp);
	} else
		pcred_unlock(pp);
	return 0;
}

/*
 * cap_get - get the capability set of a file
 *
 * Returns 0 on success.
 * Returns ENOATTR if no capability set is associated with the file.
 */

int
cap_get(char *fname, int fdes, struct cap_set *cap)
{
	struct cap_set kcap;
	vfile_t *fp;
	vnode_t *vp;
	int error = 0;

	if (fdes != -1 && fname != NULL)
		return (EINVAL);
	if (fdes == -1 && fname == NULL)
		return (EINVAL);

	if (!cap)
		return (EINVAL);

	_SAT_PN_BOOK(SAT_FILE_ATTR_READ, curuthread);

	if (fname) {
		if (error=lookupname(fname,UIO_USERSPACE,NO_FOLLOW,NULLVPP,&vp,						NULL))
			return (error);
	}
	else {
		if (error = getf(fdes, &fp))
			return (error);
		if (!VF_IS_VNODE(fp))
			return (EINVAL);
		vp = VF_TO_VNODE(fp);

		VN_HOLD(vp);
	}

	if (!(error = _MAC_VACCESS(vp, curuthread->ut_cred, VREAD)))
	    error = cap_vtocap(vp, &kcap); /* Returns ENOATTR if no capability set */

	if (!error) {
		if (copyout((caddr_t)&kcap,(caddr_t)cap,sizeof(struct cap_set)))
			error = EFAULT;
	}
	
	VN_RELE(vp);

	_SAT_ACCESS(SAT_FILE_ATTR_READ, error);
	return (error);
}

/*
 * cap_set - set the capability set on a file
 *
 * If cap is a null pointer, the capability set is removed from
 * the file.
 *
 * Returns 0 on success.
 */

int
cap_set(char *fname, int fdes, struct cap_set *cap)
{
	struct cap_set kcap;
	vnode_t *vp;
	vfile_t *fp;
	int error;

	if (!_CAP_ABLE(CAP_SETFCAP))
		return (EPERM);

	if (fdes != -1 && fname != NULL)
		return (EINVAL);
	if (fdes == -1 && fname == NULL)
		return (EINVAL);


	if (cap && copyin((caddr_t)cap, (caddr_t)&kcap, sizeof(struct cap_set)))
		return (EFAULT);

	_SAT_PN_BOOK(SAT_FILE_ATTR_WRITE, curuthread);

	if (fname) {
		if (error=lookupname(fname,UIO_USERSPACE,NO_FOLLOW,NULLVPP,&vp,						NULL))
			return (error);
	}
	else {
		if (error = getf(fdes, &fp))
			return (error);
		if (!VF_IS_VNODE(fp))
			return (EINVAL);
		vp = VF_TO_VNODE(fp);
		VN_HOLD(vp);
	}

	/*
	 * MAC and ownership checks.
	 */
	if (!(error = _MAC_VACCESS(vp, curuthread->ut_cred, VWRITE))) {
		vattr_t va;

		va.va_mask = AT_UID;
		VOP_GETATTR(vp, &va, 0, sys_cred, error);

		if (!error && va.va_uid != curuthread->ut_cred->cr_uid &&
		    !_CAP_CRABLE(curuthread->ut_cred, CAP_FOWNER))
			error = EACCES;
	}

	if (!error) {
		/*
		 * Only regular files should have cap sets.
		 * Better not try to update a read-only file system.
		 */
		if (vp->v_type != VREG)
			error = EINVAL;
		else if (vp->v_vfsp->vfs_flag & VFS_RDONLY)
			error = EROFS;
		else if ( cap )
		{
			VOP_ATTR_SET(vp, SGI_CAP_FILE, (char *)cap,
			    sizeof(cap_set_t), ATTR_ROOT, sys_cred, error);
		}
		else
		{
		        VOP_ATTR_REMOVE(vp, SGI_CAP_FILE, ATTR_ROOT, sys_cred, error);
			if ( error == ENOATTR )
			    /* There already was no capability associated with the file */
			    error = 0;
		}
	}

	VN_RELE(vp);
	_SAT_SETCAP( cap, error );
	return (error);
}

int
cap_style(int new)
{

#ifdef DEBUG
	if (cap_enabled == CAP_SYS_SUPERUSER)
		cmn_err(CE_NOTE,"Superuser and capabilities provide privilege");
	else if (cap_enabled == CAP_SYS_NO_SUPERUSER)
		cmn_err(CE_NOTE,"Capabilities alone provide privilege");
	else if (cap_enabled == CAP_SYS_DISABLED)
		cmn_err(CE_NOTE,"Superuser alone provides privilege");
#endif /* DEBUG */

	if (!_CAP_ABLE(CAP_SYSINFO_MGT))
		return (EPERM);

#ifdef DEBUG
	if (new == CAP_SYS_SUPERUSER)
		cmn_err(CE_NOTE,
		    "Now, Superuser and capabilities provide privilege");
	else if (new == CAP_SYS_NO_SUPERUSER)
		cmn_err(CE_NOTE,"Now, Capabilities alone provide privilege");
	else if (new == CAP_SYS_DISABLED)
		cmn_err(CE_NOTE,"Now, Superuser alone provides privilege");
#endif /* DEBUG */
	cap_enabled = new;
	return (0);
}

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Casey Schaufler (casey@schaufler-ca.com):
> 
> 
> --- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> 
> 
> > +
> > +	bprm->cap_effective = fscaps[0];
> > +	bprm->cap_inheritable = fscaps[1];
> > +	bprm->cap_permitted = fscaps[2];
> > +
> 
> It does not appear that you're attempting
> to maintain the POSIX exec semantics for
> capability sets. (If you're doing it
> elsewhere in the code, nevermind) I don't
> know if this is intentional or not.

It should be getting done correctly at bprm_apply_creds.
The code you quote here is just setting it on the
binprm, which represents the executable itself (and as
pointed out in the comment above it).

Now the cap_bprm_secureexec() function needs to be
updated as I believe I pointed out in the original
submission.  But if anything else is not getting done
right please correct me.

> I will have a closer look, but just for
> grins, I've attached code from the SGI
> OB1 offering of some years back that
> includes a function, cap_recalc, that
> implements the correct behavior. I will
> also take a stab at working it in, but

Excellent, thanks.

> I expect someone will beat me to it.

-serge

Re: [RFC] [PATCH] file posix capabilities

[Albert Cahalan]

Casey Schaufler writes:
> --- "Serge E. Hallyn" <serue@us.ibm.com> wrote:

>> +    bprm->cap_effective = fscaps[0];
>> +    bprm->cap_inheritable = fscaps[1];
>> +    bprm->cap_permitted = fscaps[2];
>
> It does not appear that you're attempting
> to maintain the POSIX exec semantics for
> capability sets. (If you're doing it
> elsewhere in the code, nevermind) I don't
> know if this is intentional or not.

Stop right there. No such POSIX semantics exist.
There is no POSIX standard for this. Out in the
wild there are numerous dangerously incompatible
ideas about this concept:

a. SGI IRIX, and one draft of a failed POSIX proposal
b. Linux (half done), and a very different draft
c. DG-UX, which actually had a workable system
d. Solaris, which is workable and getting used

My rant from 4 years ago mostly applies today.
http://lkml.org/lkml/2003/10/22/135

(yes, we have a lame SGI-style set of bits with
a set of equations that is not compatible)

Something has changed though: people are actually
using this type of thing on Solaris. Probably the
sanest thing to do is to copy Solaris: equations,
tools, set of bits, #define names, API, etc. Just
let Sun be the standard, and semi-portable apps
will be able to use the feature. Cross-platform
admins will be very grateful for the consistency.

Re: [RFC] [PATCH] file posix capabilities

[Serge E. Hallyn]

Quoting Albert Cahalan (acahalan@gmail.com):
> Casey Schaufler writes:
> >--- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> 
> >>+    bprm->cap_effective = fscaps[0];
> >>+    bprm->cap_inheritable = fscaps[1];
> >>+    bprm->cap_permitted = fscaps[2];
> >
> >It does not appear that you're attempting
> >to maintain the POSIX exec semantics for
> >capability sets. (If you're doing it
> >elsewhere in the code, nevermind) I don't
> >know if this is intentional or not.
> 
> Stop right there. No such POSIX semantics exist.
> There is no POSIX standard for this. Out in the
> wild there are numerous dangerously incompatible
> ideas about this concept:
> 
> a. SGI IRIX, and one draft of a failed POSIX proposal
> b. Linux (half done), and a very different draft
> c. DG-UX, which actually had a workable system
> d. Solaris, which is workable and getting used
> 
> My rant from 4 years ago mostly applies today.
> http://lkml.org/lkml/2003/10/22/135
> 
> (yes, we have a lame SGI-style set of bits with
> a set of equations that is not compatible)
> 
> Something has changed though: people are actually
> using this type of thing on Solaris. Probably the
> sanest thing to do is to copy Solaris: equations,
> tools, set of bits, #define names, API, etc. Just
> let Sun be the standard, and semi-portable apps
> will be able to use the feature. Cross-platform
> admins will be very grateful for the consistency.

Does anyone have a security/solaris_prm.ko module they've
been quietly working on or using?

(given the number of fscaps patches out there, it seems a
reasonable question)

thanks,
-serge

Re: [RFC] [PATCH] file posix capabilities

[Casey Schaufler]

--- Albert Cahalan <acahalan@gmail.com> wrote:

> Casey Schaufler writes:
> > --- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> 
> >> +    bprm->cap_effective = fscaps[0];
> >> +    bprm->cap_inheritable = fscaps[1];
> >> +    bprm->cap_permitted = fscaps[2];
> >
> > It does not appear that you're attempting
> > to maintain the POSIX exec semantics for
> > capability sets. (If you're doing it
> > elsewhere in the code, nevermind) I don't
> > know if this is intentional or not.
> 
> Stop right there. No such POSIX semantics exist.
> There is no POSIX standard for this.

Strictly speaking you are of course correct.
Please accept my appologies and pass them along
to the IEEE.

> Out in the
> wild there are numerous dangerously incompatible
> ideas about this concept:
> 
> a. SGI IRIX, and one draft of a failed POSIX
> proposal

There were 17 drafts. I believe the one you
refer to is the last, which was withdrawn
due to lack of participation.

> b. Linux (half done), and a very different draft

A very similar draft. The differences are not
so significant as to matter much.

> c. DG-UX, which actually had a workable system

Opinions vary!

> d. Solaris, which is workable and getting used

Ok.
 
> Something has changed though: people are actually
> using this type of thing on Solaris. Probably the
> sanest thing to do is to copy Solaris: equations,
> tools, set of bits, #define names, API, etc. Just
> let Sun be the standard, and semi-portable apps
> will be able to use the feature. Cross-platform
> admins will be very grateful for the consistency.

There are worse notions floating about.
I personally prefer the scheme used in
Irix (big surprise there) but I certainly
wouldn't obstruct a concerted effort to
go the Solaris route. 


Casey Schaufler
casey@schaufler-ca.com