Quoting Eric W. Biederman ([email protected]):
> "Serge E. Hallyn" <[email protected]> writes:
>
> > Quoting Serge E. Hallyn ([email protected]):
> >> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
