Messages in this thread | | | Date | Mon, 14 Aug 2006 21:06:47 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC] [PATCH] file posix capabilities |
| |
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/
| |