-----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];
};
> +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
- an old capability (eg. CAP_SYS_ADMIN) is split into two
In the old kernel how could the 'desired behavior' for the new file
attribute be guessed correctly?
Thanks
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGt8R1+bHCR3gb8jsRAu7uAJ90uUlXbRmbm0RioNFSpGYrLDh2SQCg0YEc
49Uj9Vt0suz9ntJIM4CjFYo=
=tVr2
-----END PGP SIGNATURE-----
-
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
