Quoting Andrew G. Morgan ([EMAIL PROTECTED]):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -long cap_prctl_drop(unsigned long cap)
> +static long cap_prctl_drop(unsigned long cap)
> ~ {
> - - if (!capable(CAP_SETPCAP))
> + if (cap_capable(current, CAP_SETPCAP) != 0)
>
> | With this change, you
>
> | a) prevent PF_SUPERPRIV being set, although the task did
> | explicitly attempt a privileged operation.
>
> | b) stop checking other security modules, so for instance
> | selinux no longer gets a say in dropping of
> | capabilities.
>
> | Are these both intended?
>
> No. They were an oversight while I was trimming the patch. Good catch!
>
> + default:
> + /* No functionality available - continue with default */
> + return 0;
>
> | Hmm, if CONFIG_SECURITY_FILE_CAPABILITIES=n and cmd is one of the above
> | like PR_CAPBSET_DROP, do we want to return 0 and allow someone else to
> | handle these, or is it more appropriate to return -EINVAL?
>
> My feeling was that if this functionality is not configured, then I
> didn't want to alter legacy expectations.
>
> I very much wanted to limit this change to affect only those brave souls
> willing to use the "experimental" filesystem support for capabilities.
Ok - there's no LSM that I know of right now that would try to hijack
these anyway :)
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
