Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Serge E. Hallyn wrote:
> > Andrew, James, Stephen, Chris,
> >
> > The following is all-but-untested (just compiles with relevant config
> > combinations). But is each of you ok with the following approach for
> > handling unknown capabilities?
>
> I'd prefer a version that looks like:
>
> struct vfs_cap_data_v2 {
> __u32 magic_etc; /* Little endian */
> struct {
> __u32 permitted; /* Little endian */
> __u32 inheritable; /* Little endian */
> } data[2];
> };
That's fine with me.
> > +config SECURITYFILE_CAPS_STRICT
> > + bool "Refuse to run files with unknown capabilities"
> > + depends on SECURITY_FILE_CAPABILITIES
> > + default y
> > + help
> > + Refuse to run files which have unknown capabilities set
> > + in the security.capability xattr. This could prevent
> > + running important binaries from an updated distribution
> > + on an older kernel.
>
> But this sort of implies that we know something about the future
> capabilities.
>
> So far as I can see there are two types of issue:
>
> - a new capability comes along - it is needed to run an app
As an example, CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL were
added along with new features they control. Allowing the
audit daemon to run gives it a chance to tell the admin that
the kernel is too old. Refusing execve probably suggests
the same thing, though it may be more confusing. But in
any case it seems likely to me that a new capability will
protect a new feature, which will not be present, so the
lack of the capability will be no more dangerous than the
lack of the feature.
> - an old capability (eg. CAP_SYS_ADMIN) is split into two
This particular case would be cause to bump the version number, since
the meaning of existing cap bits has changed. If the version # is
bumped to 3, the patch I sent will still return -EINVAL.
> In the old kernel how could the 'desired behavior' for the new file
> attribute be guessed correctly?
It can't.
Whoever is introducing the new capability will need to decide
whether it warrants bumping the version #.
thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
