Re: [RFC] [PATCH] file posix capabilities

["Serge E. Hallyn" <serue@us.ibm.com>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/