PATH records show fcaps

PATH records show fcaps

[Eric Paris]

type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=EXECVE msg=audit(1224342849.465:43): argc=2 a0="ping" a1="127.0.0.1" 
type=CWD msg=audit(1224342849.465:43):  cwd="/root"
type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000 cap_inheritable=0000000000000000
type=PATH msg=audit(1224342849.465:43): item=1 name=(null) inode=507963 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0

This good?  If either cap_permitted or cap_inheritable have anything set
I show them both.  In the above example would you rather I only showed
cap_permitted and dropped cap_inheritable?  Did I see correctly that
it's possible to set a cap_effective on a file?  Does it do anything?  I
didn't see that getting used or read in the kernel, so I didn't put any
way to display it in kernel....

-Eric

---

 include/linux/capability.h |   11 ++++
 kernel/auditsc.c           |   68 ++++++++++++++++++++++++--
 security/commoncap.c       |  115 +++++++++++++++++++++++++-------------------
 3 files changed, 140 insertions(+), 54 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 9d1fe30..a3785e7 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -96,6 +96,13 @@ typedef struct kernel_cap_struct {
 	__u32 cap[_KERNEL_CAPABILITY_U32S];
 } kernel_cap_t;
 
+/* exact same as vfs_cap_data but in cpu endian and always filled completely */
+struct cpu_vfs_cap_data {
+	__u32 magic_etc;
+	kernel_cap_t permitted;
+	kernel_cap_t inheritable;
+};
+
 #define _USER_CAP_HEADER_SIZE  (sizeof(struct __user_cap_header_struct))
 #define _KERNEL_CAP_T_SIZE     (sizeof(kernel_cap_t))
 
@@ -517,6 +524,10 @@ kernel_cap_t cap_set_effective(const kernel_cap_t pE_new);
 
 extern int capable(int cap);
 
+/* audit system wants to get cap info from files as well */
+struct dentry;
+extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
+
 #endif /* __KERNEL__ */
 
 #endif /* !_LINUX_CAPABILITY_H */
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index cf5bc2f..800fc55 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -65,6 +65,7 @@
 #include <linux/highmem.h>
 #include <linux/syscalls.h>
 #include <linux/inotify.h>
+#include <linux/capability.h>
 
 #include "audit.h"
 
@@ -100,6 +101,8 @@ struct audit_names {
 	gid_t		gid;
 	dev_t		rdev;
 	u32		osid;
+	kernel_cap_t	cap_permitted;
+	kernel_cap_t	cap_inheritable;
 };
 
 struct audit_aux_data {
@@ -1171,6 +1174,33 @@ static void audit_log_execve_info(struct audit_context *context,
 	kfree(buf);
 }
 
+static void audit_log_fcaps(struct audit_buffer *ab, struct audit_names *name)
+{
+	int i;
+	int print = 0;
+	kernel_cap_t *perm = &name->cap_permitted;
+	kernel_cap_t *inh = &name->cap_inheritable;
+
+	CAP_FOR_EACH_U32(i) {
+		if (perm->cap[i] || inh->cap[i]) {
+			print = 1;
+			break;
+		}
+	}
+
+	if (likely(!print))
+		return;
+
+	audit_log_format(ab, " %s", "cap_permitted=");
+        CAP_FOR_EACH_U32(i) {
+                audit_log_format(ab, "%08x", perm->cap[(_KERNEL_CAPABILITY_U32S-1) - i]);
+        }
+	audit_log_format(ab, " %s", "cap_inheritable=");
+        CAP_FOR_EACH_U32(i) {
+                audit_log_format(ab, "%08x", inh->cap[(_KERNEL_CAPABILITY_U32S-1) - i]);
+        }
+}
+
 static void audit_log_exit(struct audit_context *context, struct task_struct *tsk)
 {
 	int i, call_panic = 0;
@@ -1421,6 +1451,8 @@ static void audit_log_exit(struct audit_context *context, struct task_struct *ts
 			}
 		}
 
+		audit_log_fcaps(ab, n);
+
 		audit_log_end(ab);
 	}
 
@@ -1787,8 +1819,33 @@ static int audit_inc_name_count(struct audit_context *context,
 	return 0;
 }
 
+
+static inline int audit_copy_fcaps(struct audit_names *name, const struct dentry *dentry)
+{
+	struct cpu_vfs_cap_data caps;
+	int rc, i;
+
+	memset(&name->cap_permitted, 0, sizeof(kernel_cap_t));
+	memset(&name->cap_inheritable, 0, sizeof(kernel_cap_t));
+
+	if (!dentry)
+		return 0;
+
+	rc = get_vfs_caps_from_disk(dentry, &caps);
+	if (rc)
+		return rc;
+
+	CAP_FOR_EACH_U32(i) {
+		name->cap_permitted.cap[i] = caps.permitted.cap[i];
+		name->cap_inheritable.cap[i] = caps.inheritable.cap[i];
+	}
+	return 0;
+}
+
+
 /* Copy inode data into an audit_names. */
-static void audit_copy_inode(struct audit_names *name, const struct inode *inode)
+static void audit_copy_inode(struct audit_names *name, const struct dentry *dentry,
+			     const struct inode *inode)
 {
 	name->ino   = inode->i_ino;
 	name->dev   = inode->i_sb->s_dev;
@@ -1797,6 +1854,7 @@ static void audit_copy_inode(struct audit_names *name, const struct inode *inode
 	name->gid   = inode->i_gid;
 	name->rdev  = inode->i_rdev;
 	security_inode_getsecid(inode, &name->osid);
+	audit_copy_fcaps(name, dentry);
 }
 
 /**
@@ -1831,7 +1889,7 @@ void __audit_inode(const char *name, const struct dentry *dentry)
 		context->names[idx].name = NULL;
 	}
 	handle_path(dentry);
-	audit_copy_inode(&context->names[idx], inode);
+	audit_copy_inode(&context->names[idx], dentry, inode);
 }
 
 /**
@@ -1892,7 +1950,7 @@ void __audit_inode_child(const char *dname, const struct dentry *dentry,
 		if (!strcmp(dname, n->name) ||
 		     !audit_compare_dname_path(dname, n->name, &dirlen)) {
 			if (inode)
-				audit_copy_inode(n, inode);
+				audit_copy_inode(n, NULL, inode);
 			else
 				n->ino = (unsigned long)-1;
 			found_child = n->name;
@@ -1906,7 +1964,7 @@ add_names:
 			return;
 		idx = context->name_count - 1;
 		context->names[idx].name = NULL;
-		audit_copy_inode(&context->names[idx], parent);
+		audit_copy_inode(&context->names[idx], NULL, parent);
 	}
 
 	if (!found_child) {
@@ -1927,7 +1985,7 @@ add_names:
 		}
 
 		if (inode)
-			audit_copy_inode(&context->names[idx], inode);
+			audit_copy_inode(&context->names[idx], NULL, inode);
 		else
 			context->names[idx].ino = (unsigned long)-1;
 	}
diff --git a/security/commoncap.c b/security/commoncap.c
index 399bfdb..9f109b9 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -202,17 +202,70 @@ int cap_inode_killpriv(struct dentry *dentry)
 	return inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
 }
 
-static inline int cap_from_disk(struct vfs_cap_data *caps,
-				struct linux_binprm *bprm, unsigned size)
+static inline int bprm_caps_from_vfs_caps(struct cpu_vfs_cap_data *caps,
+					  struct linux_binprm *bprm)
 {
+	unsigned i;
+	int ret = 0;
+
+	if (caps->magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
+		bprm->cap_effective = true;
+	else
+		bprm->cap_effective = false;
+
+	CAP_FOR_EACH_U32(i) {
+		__u32 permitted = caps->permitted.cap[i];
+		__u32 inheritable = caps->inheritable.cap[i];
+
+		/*
+		 * pP' = (X & fP) | (pI & fI)
+		 */
+		bprm->cap_post_exec_permitted.cap[i] =
+			(current->cap_bset.cap[i] & permitted) |
+			(current->cap_inheritable.cap[i] & inheritable);
+
+		if (permitted & ~bprm->cap_post_exec_permitted.cap[i]) {
+			/*
+			 * insufficient to execute correctly
+			 */
+			ret = -EPERM;
+		}
+	}
+
+	/*
+	 * For legacy apps, with no internal support for recognizing they
+	 * do not have enough capabilities, we return an error if they are
+	 * missing some "forced" (aka file-permitted) capabilities.
+	 */
+	return bprm->cap_effective ? ret : 0;
+}
+
+int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps)
+{
+	struct inode *inode = dentry->d_inode;
 	__u32 magic_etc;
 	unsigned tocopy, i;
-	int ret;
+	int size;
+	struct vfs_cap_data caps;
+
+	memset(cpu_caps, 0, sizeof(struct cpu_vfs_cap_data));
+
+	if (!inode || !inode->i_op || !inode->i_op->getxattr)
+		return 0;
+
+	size = inode->i_op->getxattr((struct dentry *)dentry, XATTR_NAME_CAPS, &caps,
+				   XATTR_CAPS_SZ);
+	if (size == -ENODATA || size == -EOPNOTSUPP) {
+		/* no data, that's ok */
+		return 0;
+	}
+	if (size < 0)
+		return size;
 
 	if (size < sizeof(magic_etc))
 		return -EINVAL;
 
-	magic_etc = le32_to_cpu(caps->magic_etc);
+	cpu_caps->magic_etc = magic_etc = le32_to_cpu(caps.magic_etc);
 
 	switch ((magic_etc & VFS_CAP_REVISION_MASK)) {
 	case VFS_CAP_REVISION_1:
@@ -229,46 +282,16 @@ static inline int cap_from_disk(struct vfs_cap_data *caps,
 		return -EINVAL;
 	}
 
-	if (magic_etc & VFS_CAP_FLAGS_EFFECTIVE) {
-		bprm->cap_effective = true;
-	} else {
-		bprm->cap_effective = false;
-	}
-
-	ret = 0;
-
 	CAP_FOR_EACH_U32(i) {
-		__u32 value_cpu;
-
-		if (i >= tocopy) {
-			/*
-			 * Legacy capability sets have no upper bits
-			 */
-			bprm->cap_post_exec_permitted.cap[i] = 0;
+		if (i > tocopy) {
+			cpu_caps->permitted.cap[i] = 0;
+			cpu_caps->inheritable.cap[i] = 0;
 			continue;
 		}
-		/*
-		 * pP' = (X & fP) | (pI & fI)
-		 */
-		value_cpu = le32_to_cpu(caps->data[i].permitted);
-		bprm->cap_post_exec_permitted.cap[i] =
-			(current->cap_bset.cap[i] & value_cpu) |
-			(current->cap_inheritable.cap[i] &
-				le32_to_cpu(caps->data[i].inheritable));
-		if (value_cpu & ~bprm->cap_post_exec_permitted.cap[i]) {
-			/*
-			 * insufficient to execute correctly
-			 */
-			ret = -EPERM;
-		}
+		cpu_caps->permitted.cap[i] = le32_to_cpu(caps.data[i].permitted);
+		cpu_caps->inheritable.cap[i] = le32_to_cpu(caps.data[i].inheritable);
 	}
-
-	/*
-	 * For legacy apps, with no internal support for recognizing they
-	 * do not have enough capabilities, we return an error if they are
-	 * missing some "forced" (aka file-permitted) capabilities.
-	 */
-	return bprm->cap_effective ? ret : 0;
+	return 0;
 }
 
 /* Locate any VFS capabilities: */
@@ -276,7 +299,7 @@ static int get_file_caps(struct linux_binprm *bprm)
 {
 	struct dentry *dentry;
 	int rc = 0;
-	struct vfs_cap_data vcaps;
+	struct cpu_vfs_cap_data vcaps;
 	struct inode *inode;
 
 	if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
@@ -289,17 +312,11 @@ static int get_file_caps(struct linux_binprm *bprm)
 	if (!inode->i_op || !inode->i_op->getxattr)
 		goto out;
 
-	rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, &vcaps,
-				   XATTR_CAPS_SZ);
-	if (rc == -ENODATA || rc == -EOPNOTSUPP) {
-		/* no data, that's ok */
-		rc = 0;
-		goto out;
-	}
+	rc = get_vfs_caps_from_disk(dentry, &vcaps);
 	if (rc < 0)
 		goto out;
 
-	rc = cap_from_disk(&vcaps, bprm, rc);
+	rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
 	if (rc == -EINVAL)
 		printk(KERN_NOTICE "%s: cap_from_disk returned %d for %s\n",
 		       __func__, rc, bprm->filename);

Re: PATH records show fcaps

[Steve Grubb]

On Saturday 18 October 2008 11:23:12 Eric Paris wrote:
> type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227
> dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
> obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000
> cap_inheritable=0000000000000000 

The kernel abbreviates these as: capprm & capinh in the proc file system. I'm 
thinking shorter names would save some disk space.

> This good?  If either cap_permitted or cap_inheritable have anything set
> I show them both.

And they are otherwise missing to save disk space?

> In the above example would you rather I only showed 
> cap_permitted and dropped cap_inheritable?

No. Its my understanding that apps could have something inheritable by 
children and we'd want to know exactly what that was.

> Did I see correctly that it's possible to set a cap_effective on a file? 

Yes.

> Does it do anything?  I didn't see that getting used or read in the kernel, 
> so I didn't put any way to display it in kernel....

That would be strange to have a field that is not used.

I'll leave code review to others. Thanks for working on this patch!

-Steve

Re: PATH records show fcaps

[Eric Paris]

On Mon, 2008-10-20 at 06:56 -0400, Steve Grubb wrote:
> On Saturday 18 October 2008 11:23:12 Eric Paris wrote:
> > type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227
> > dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000
> > cap_inheritable=0000000000000000 
> 
> The kernel abbreviates these as: capprm & capinh in the proc file system. I'm 
> thinking shorter names would save some disk space.
> 
> > This good?  If either cap_permitted or cap_inheritable have anything set
> > I show them both.
> 
> And they are otherwise missing to save disk space?

Yes, see the example  :)

> > In the above example would you rather I only showed 
> > cap_permitted and dropped cap_inheritable?
> 
> No. Its my understanding that apps could have something inheritable by 
> children and we'd want to know exactly what that was.

Notice this record is only about the perms on the file.  My question was
that in the above example I have a capprm set on the file but I do not
have a capinh set on the file.  To save space would you rather I only
showed the capprm or should I show the 0 capinh as well?  The opposite
would also be true, if I had capinh set on a file but didn't have capprm
set should I display only the capinh or display both capinh and a blank
capprm?

Re: PATH records show fcaps

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=EXECVE msg=audit(1224342849.465:43): argc=2 a0="ping" a1="127.0.0.1" 
> type=CWD msg=audit(1224342849.465:43):  cwd="/root"
> type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000 cap_inheritable=0000000000000000
> type=PATH msg=audit(1224342849.465:43): item=1 name=(null) inode=507963 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
> 
> This good?  If either cap_permitted or cap_inheritable have anything set
> I show them both.  In the above example would you rather I only showed
> cap_permitted and dropped cap_inheritable?  Did I see correctly that

I think dropping the empty one is fine.

Steve's suggestion of cap_prm and cap_inh are good for being shorter and
matching proc output.  But OTOH it's a bit confusing as at first I
thought these were the task's values.  Would it be too terse to just
use fP and fI?

> it's possible to set a cap_effective on a file?  Does it do anything?  I
> didn't see that getting used or read in the kernel, so I didn't put any
> way to display it in kernel....

<background>
The idea is that putting bits in fE will cause them to be in pE' after
exec.  But the way it is interpreted is as a boolean, so either
pE' is empty or it is set to pP'.  So if you do

	setcap cap_dac_override=pe /bin/foo

then executing /bin/foo will land cap_dac_override in your effective
and permitted sets.  If you do

	setcap cap_dac_override=pe /bin/foo

then it  will land only in your permitted set.

</background>

<summary>

I thought the kernel looked at the actual contents of fE, but now I see
that instead setcap sets a VFS_CAP_FLAGS_EFFECTIVE flag in the
capability xattr magic value.  So the effective value appears to be
unused.  But the VFS_CAP_FLAGS_EFFECTIVE (aka 'legacy bit'), if set, is
obviously very important, and should be printed out, at least if it is
set.  Perhaps just 'cap_legacy=true' if it's set?

And actually the capability revision # might be useful too.  Perhaps
output that only if it doesn't match kernel default (VFS_CAP_REVISION)?

</summary>

-serge

Re: PATH records show fcaps

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

This part above is the credentials of the running task, right?  Will it
output your process inheritable set if nonempty?

(I would think you should be able to test this by doing

	capsh --inh=cap_sys_admin /bin/sh
	/bin/foo

and look for /bin/foo's record)

thanks,
-serge

Re: PATH records show fcaps

[Eric Paris]

On Mon, 2008-10-20 at 11:31 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> > type=EXECVE msg=audit(1224342849.465:43): argc=2 a0="ping" a1="127.0.0.1" 
> > type=CWD msg=audit(1224342849.465:43):  cwd="/root"
> > type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000 cap_inheritable=0000000000000000
> > type=PATH msg=audit(1224342849.465:43): item=1 name=(null) inode=507963 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
> > 
> > This good?  If either cap_permitted or cap_inheritable have anything set
> > I show them both.  In the above example would you rather I only showed
> > cap_permitted and dropped cap_inheritable?  Did I see correctly that
> 
> I think dropping the empty one is fine.
> 
> Steve's suggestion of cap_prm and cap_inh are good for being shorter and
> matching proc output.  But OTOH it's a bit confusing as at first I
> thought these were the task's values.  Would it be too terse to just
> use fP and fI?

yes, too terse. How about cap_fP, cap_fI, cap_fVer, cap_fEffBit ?

Based on your other comments I'm going to go add fVer and fEffBit.

Re: PATH records show fcaps

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> On Mon, 2008-10-20 at 11:31 -0500, Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis@redhat.com):
> > > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> > > type=EXECVE msg=audit(1224342849.465:43): argc=2 a0="ping" a1="127.0.0.1" 
> > > type=CWD msg=audit(1224342849.465:43):  cwd="/root"
> > > type=PATH msg=audit(1224342849.465:43): item=0 name="/bin/ping" inode=49227 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_permitted=0000000000002000 cap_inheritable=0000000000000000
> > > type=PATH msg=audit(1224342849.465:43): item=1 name=(null) inode=507963 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0
> > > 
> > > This good?  If either cap_permitted or cap_inheritable have anything set
> > > I show them both.  In the above example would you rather I only showed
> > > cap_permitted and dropped cap_inheritable?  Did I see correctly that
> > 
> > I think dropping the empty one is fine.
> > 
> > Steve's suggestion of cap_prm and cap_inh are good for being shorter and
> > matching proc output.  But OTOH it's a bit confusing as at first I
> > thought these were the task's values.  Would it be too terse to just
> > use fP and fI?
> 
> yes, too terse. How about cap_fP, cap_fI, cap_fVer, cap_fEffBit ?

Well it's a PATH record type so it should be obvious that these are file
caps, so better to stick with Steve's suggestions, right?

> Based on your other comments I'm going to go add fVer and fEffBit.

cap_ver and cap_legacy?

I can't explain it, but fEffBit makes me think of Twiki...

thanks,
-serge

Re: PATH records show fcaps

[Eric Paris]

On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> 
> This part above is the credentials of the running task, right?  Will it
> output your process inheritable set if nonempty?
> 
> (I would think you should be able to test this by doing
> 
> 	capsh --inh=cap_sys_admin /bin/sh
> 	/bin/foo
> 
> and look for /bin/foo's record)
> 
> thanks,
> -serge

For this (patch 2) I'm adding information so you can tell a process
escalated it privs with fcaps.  This really means you have to audit
EXECVE (since this is when fcaps are applied)

setcap "cap_net_admin+pei" /bin/bash
setcap "cap_net_raw+pei" /bin/ping

auditctl -a exit,always -S execve -F path=/bin/ping

type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=1 name=(null) inode=507963 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 
type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=0 name=/bin/ping inode=49227 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fP=0000000000002000 cap_fE=1 cap_fVer=2
type=CWD msg=audit(10/20/2008 13:27:55.318:218) :  cwd=/home/test 
type=UNKNOWN[1321] msg=audit(10/20/2008 13:27:55.318:218) :  cap_fP=0000000000002000 cap_fI=0000000000000000 cap_fE=1 cap_pP=0000000000001000 cap_pI=0000000000000000 cap_pE=0000000000001000 cap_bprmE=0000000000002000 
type=EXECVE msg=audit(10/20/2008 13:27:55.318:218) : argc=(null) a0=ping a1=127.0.0.1 
type=SYSCALL msg=audit(10/20/2008 13:27:55.318:218) : arch=x86_64 syscall=execve success=yes exit=0 a0=2225590 a1=22257e0 a2=223ae30 a3=3445170a70 items=2 ppid=2994 pid=3023 auid=root uid=test gid=test euid=test suid=test fsuid=test egid=test sgid=test fsgid=test tty=pts0 ses=1 comm=ping exe=/bin/ping subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

My initial shell shows in /proc/self/status (matches above)
CapInh:	0000000000000000
CapPrm:	0000000000001000
CapEff:	0000000000001000
CapBnd:	ffffffffffffffff

So looking at this type=UNKNOWN line is the most interesting.  I do a
if(!issubset(cap_bprmEff, pP & pI).  I probaly should add a
if(fE && !issubset(cap_bprmEff, pE & pI)) as well.  So, if we are going
to change pP (and possibly pE) something like the above set of audit
messages is going to pop out.  In this case my login shell is ppid=2994
and the pid=3023 is the ping program executing.  Ping worked just fine.

Take note that at this point in the code pE and pP still show
cap_net_admin (from the /bin/bash fcap) but when ping actually finishes
execve and runs it won't have that cap since it isn't in pI.

Patch #3 is going to display more information for sys_capset (assuming
you turn on auditctl -a exit,always -S capset).  I already wrote that
patch but now I need to figure out a program that call sys_capset...

-Eric

Re: PATH records show fcaps

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis@redhat.com):
> > > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> > 
> > This part above is the credentials of the running task, right?  Will it
> > output your process inheritable set if nonempty?
> > 
> > (I would think you should be able to test this by doing
> > 
> > 	capsh --inh=cap_sys_admin /bin/sh
> > 	/bin/foo
> > 
> > and look for /bin/foo's record)
> > 
> > thanks,
> > -serge
> 
> For this (patch 2) I'm adding information so you can tell a process
> escalated it privs with fcaps.  This really means you have to audit
> EXECVE (since this is when fcaps are applied)
> 
> setcap "cap_net_admin+pei" /bin/bash
> setcap "cap_net_raw+pei" /bin/ping
> 
> auditctl -a exit,always -S execve -F path=/bin/ping
> 
> type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=1 name=(null) inode=507963 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 
> type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=0 name=/bin/ping inode=49227 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fP=0000000000002000 cap_fE=1 cap_fVer=2
> type=CWD msg=audit(10/20/2008 13:27:55.318:218) :  cwd=/home/test 
> type=UNKNOWN[1321] msg=audit(10/20/2008 13:27:55.318:218) :  cap_fP=0000000000002000 cap_fI=0000000000000000 cap_fE=1 cap_pP=0000000000001000 cap_pI=0000000000000000 cap_pE=0000000000001000 cap_bprmE=0000000000002000 

This looks wrong - you say above that you set cap_net_raw in fI for
ping, but this shows fI as empty?

-serge

Re: PATH records show fcaps

[Eric Paris]

On Mon, 2008-10-20 at 13:13 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote:
> > > Quoting Eric Paris (eparis@redhat.com):
> > > > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> > > 
> > > This part above is the credentials of the running task, right?  Will it
> > > output your process inheritable set if nonempty?
> > > 
> > > (I would think you should be able to test this by doing
> > > 
> > > 	capsh --inh=cap_sys_admin /bin/sh
> > > 	/bin/foo
> > > 
> > > and look for /bin/foo's record)
> > > 
> > > thanks,
> > > -serge
> > 
> > For this (patch 2) I'm adding information so you can tell a process
> > escalated it privs with fcaps.  This really means you have to audit
> > EXECVE (since this is when fcaps are applied)
> > 
> > setcap "cap_net_admin+pei" /bin/bash
> > setcap "cap_net_raw+pei" /bin/ping
> > 
> > auditctl -a exit,always -S execve -F path=/bin/ping
> > 
> > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=1 name=(null) inode=507963 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 
> > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=0 name=/bin/ping inode=49227 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fP=0000000000002000 cap_fE=1 cap_fVer=2
> > type=CWD msg=audit(10/20/2008 13:27:55.318:218) :  cwd=/home/test 
> > type=UNKNOWN[1321] msg=audit(10/20/2008 13:27:55.318:218) :  cap_fP=0000000000002000 cap_fI=0000000000000000 cap_fE=1 cap_pP=0000000000001000 cap_pI=0000000000000000 cap_pE=0000000000001000 cap_bprmE=0000000000002000 
> 
> This looks wrong - you say above that you set cap_net_raw in fI for
> ping, but this shows fI as empty?

/*
 * pP' = (X & fP) | (pI & fI)
 */

Not going to disagree that is weird but fcaps aren't inheritable from my
looking at the code.  Both fP and fI get collapsed by the above equation
(X is the per process bounding set) into bprm->cap_post_exec_permitted.
Then at the end of execve, cap_bprm_apply_creds(), you get:

bprm->cap_post_exec_permitted = cap_intersect(bprm->cap_post_exec_permitted,
                                              current->cap_permitted);
[snip]
current->cap_permitted = bprm->cap_post_exec_permitted;
if (bprm->cap_effective)
        current->cap_effective = bprm->cap_post_exec_permitted;

fcaps at least from my reading are not inheritable and basically it
looks to me like the only thing fI really means is that they can get
pushed into pP (and pE) if they intersect with pI.

/me doesn't really mind having fI not be inheritable.  Although I'm not
sure why we need that weird twist on the meaning fI....

-Eric

Re: PATH records show fcaps

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> On Mon, 2008-10-20 at 13:13 -0500, Serge E. Hallyn wrote:
> > Quoting Eric Paris (eparis@redhat.com):
> > > On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote:
> > > > Quoting Eric Paris (eparis@redhat.com):
> > > > > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> > > > 
> > > > This part above is the credentials of the running task, right?  Will it
> > > > output your process inheritable set if nonempty?
> > > > 
> > > > (I would think you should be able to test this by doing
> > > > 
> > > > 	capsh --inh=cap_sys_admin /bin/sh
> > > > 	/bin/foo
> > > > 
> > > > and look for /bin/foo's record)
> > > > 
> > > > thanks,
> > > > -serge
> > > 
> > > For this (patch 2) I'm adding information so you can tell a process
> > > escalated it privs with fcaps.  This really means you have to audit
> > > EXECVE (since this is when fcaps are applied)
> > > 
> > > setcap "cap_net_admin+pei" /bin/bash
> > > setcap "cap_net_raw+pei" /bin/ping
> > > 
> > > auditctl -a exit,always -S execve -F path=/bin/ping
> > > 
> > > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=1 name=(null) inode=507963 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 
> > > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=0 name=/bin/ping inode=49227 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fP=0000000000002000 cap_fE=1 cap_fVer=2
> > > type=CWD msg=audit(10/20/2008 13:27:55.318:218) :  cwd=/home/test 
> > > type=UNKNOWN[1321] msg=audit(10/20/2008 13:27:55.318:218) :  cap_fP=0000000000002000 cap_fI=0000000000000000 cap_fE=1 cap_pP=0000000000001000 cap_pI=0000000000000000 cap_pE=0000000000001000 cap_bprmE=0000000000002000 
> > 
> > This looks wrong - you say above that you set cap_net_raw in fI for
> > ping, but this shows fI as empty?
> 
> /*
>  * pP' = (X & fP) | (pI & fI)
>  */
> 
> Not going to disagree that is weird but fcaps aren't inheritable from my

I'm not saying I expected to see them in pP.  I'm saying that you report
cap_fI as empty.  I assume cap_fI should be fI straight out of the
xattr.  Above you said you put cap_net_raw into fI.

So unless you had actually done 'setcap "cap_net_raw+pe" /bin/ping'
before collecting that audit record, it looks like you've got a bug
in grabbing fI.

(As for the way fI is used, you are exactliy right - it is masked
against pI then placed in pP'.  The idea is that your process can
carry ambient privileges which are only enabled if the file lets
you, but at the same time are not enabled for tasks which don't
have it in pI.  So the example I usually use is if you have a
limited administrative role which just gets pI=cap_net_admin, and
fI on ifconfig is cap_net_admin.  Now other users (with pI=empty)
run ifconfig without privilege, and the limited admin only gets
cap_net_admin for ifconfig)

-serge

Re: PATH records show fcaps

[Eric Paris]

On Mon, 2008-10-20 at 14:13 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > On Mon, 2008-10-20 at 13:13 -0500, Serge E. Hallyn wrote:
> > > Quoting Eric Paris (eparis@redhat.com):
> > > > On Mon, 2008-10-20 at 11:33 -0500, Serge E. Hallyn wrote:
> > > > > Quoting Eric Paris (eparis@redhat.com):
> > > > > > type=SYSCALL msg=audit(1224342849.465:43): arch=c000003e syscall=59 success=yes exit=0 a0=25b6a00 a1=2580410 a2=2580140 a3=8 items=2 ppid=2219 pid=2266 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> > > > > 
> > > > > This part above is the credentials of the running task, right?  Will it
> > > > > output your process inheritable set if nonempty?
> > > > > 
> > > > > (I would think you should be able to test this by doing
> > > > > 
> > > > > 	capsh --inh=cap_sys_admin /bin/sh
> > > > > 	/bin/foo
> > > > > 
> > > > > and look for /bin/foo's record)
> > > > > 
> > > > > thanks,
> > > > > -serge
> > > > 
> > > > For this (patch 2) I'm adding information so you can tell a process
> > > > escalated it privs with fcaps.  This really means you have to audit
> > > > EXECVE (since this is when fcaps are applied)
> > > > 
> > > > setcap "cap_net_admin+pei" /bin/bash
> > > > setcap "cap_net_raw+pei" /bin/ping
> > > > 
> > > > auditctl -a exit,always -S execve -F path=/bin/ping
> > > > 
> > > > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=1 name=(null) inode=507963 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 
> > > > type=PATH msg=audit(10/20/2008 13:27:55.318:218) : item=0 name=/bin/ping inode=49227 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fP=0000000000002000 cap_fE=1 cap_fVer=2
> > > > type=CWD msg=audit(10/20/2008 13:27:55.318:218) :  cwd=/home/test 
> > > > type=UNKNOWN[1321] msg=audit(10/20/2008 13:27:55.318:218) :  cap_fP=0000000000002000 cap_fI=0000000000000000 cap_fE=1 cap_pP=0000000000001000 cap_pI=0000000000000000 cap_pE=0000000000001000 cap_bprmE=0000000000002000 
> > > 
> > > This looks wrong - you say above that you set cap_net_raw in fI for
> > > ping, but this shows fI as empty?
> > 
> > /*
> >  * pP' = (X & fP) | (pI & fI)
> >  */
> > 
> > Not going to disagree that is weird but fcaps aren't inheritable from my
> 
> I'm not saying I expected to see them in pP.  I'm saying that you report
> cap_fI as empty.  I assume cap_fI should be fI straight out of the
> xattr.  Above you said you put cap_net_raw into fI.
> 
> So unless you had actually done 'setcap "cap_net_raw+pe" /bin/ping'
> before collecting that audit record, it looks like you've got a bug
> in grabbing fI.
> 
> (As for the way fI is used, you are exactliy right - it is masked
> against pI then placed in pP'.  The idea is that your process can
> carry ambient privileges which are only enabled if the file lets
> you, but at the same time are not enabled for tasks which don't
> have it in pI.  So the example I usually use is if you have a
> limited administrative role which just gets pI=cap_net_admin, and
> fI on ifconfig is cap_net_admin.  Now other users (with pI=empty)
> run ifconfig without privilege, and the limited admin only gets
> cap_net_admin for ifconfig)

ok, I thought you were complaining the pI didn't have cap_net_admin.
The bug you spotted (I just can't read) was actually me just copy and
pasting the wrong thing into this discussion.

I think we all 'sorta' agree on what we want, I'll send 3 final patches
in an hour or two when I'm happy they work properly...

1) log fP, fE, fI, fver in PATH records
2) new record to execve when fcaps increase pE or pP
3) new record to capset which records the arguments pid, pP, pI, pE.

-Eric

-Eric

Re: PATH records show fcaps

[Serge E. Hallyn]

Quoting Eric Paris (eparis@redhat.com):
> ok, I thought you were complaining the pI didn't have cap_net_admin.
> The bug you spotted (I just can't read) was actually me just copy and
> pasting the wrong thing into this discussion.

Cool, just making sure.

> I think we all 'sorta' agree on what we want, I'll send 3 final patches
> in an hour or two when I'm happy they work properly...
> 
> 1) log fP, fE, fI, fver in PATH records
> 2) new record to execve when fcaps increase pE or pP
> 3) new record to capset which records the arguments pid, pP, pI, pE.

Great, thanks.

-serge

Re: PATH records show fcaps

[Steve Grubb]

On Monday 20 October 2008 12:55:41 Eric Paris wrote:
> > Steve's suggestion of cap_prm and cap_inh are good for being shorter and
> > matching proc output.  But OTOH it's a bit confusing as at first I
> > thought these were the task's values.  Would it be too terse to just
> > use fP and fI?
>
> yes, too terse. How about cap_fP, cap_fI, cap_fVer, cap_fEffBit ?
>
> Based on your other comments I'm going to go add fVer and fEffBit.

We don't have any audit fields with mixed cases in the field name. Let's not 
start it so that searches stay simple.

Thanks,
-Steve

Re: PATH records show fcaps

[Eric Paris]

On Mon, 2008-10-20 at 18:52 -0400, Steve Grubb wrote:
> On Monday 20 October 2008 12:55:41 Eric Paris wrote:
> > > Steve's suggestion of cap_prm and cap_inh are good for being shorter and
> > > matching proc output.  But OTOH it's a bit confusing as at first I
> > > thought these were the task's values.  Would it be too terse to just
> > > use fP and fI?
> >
> > yes, too terse. How about cap_fP, cap_fI, cap_fVer, cap_fEffBit ?
> >
> > Based on your other comments I'm going to go add fVer and fEffBit.
> 
> We don't have any audit fields with mixed cases in the field name. Let's not 
> start it so that searches stay simple.

even your /proc example has mixed case   :(

so choices

1) cap_fP, cap_fE, cap_fI
2) cap_fp, cap_fe, cap_fi
3) capprm_file, capeff_file, capinh_file

If steve feels strongly about not going down #1 (which obviously I
liked!) I vote #2.....

-Eric

Re: PATH records show fcaps

[Steve Grubb]

On Monday 20 October 2008 19:00:19 Eric Paris wrote:
> so choices
>
> 1) cap_fP, cap_fE, cap_fI
> 2) cap_fp, cap_fe, cap_fi
> 3) capprm_file, capeff_file, capinh_file
>
> If steve feels strongly about not going down #1 (which obviously I
> liked!) I vote #2.....

Yes, #2 is fine.

Thanks,
-Steve