On Thu, 2008-02-07 at 11:16 -0600, Serge E. Hallyn wrote: > Quoting Stephen Smalley (sds@xxxxxxxxxxxxx): > > Fix SELinux to handle 64-bit capabilities correctly, and to catch > > future extensions of capabilities beyond 64 bits to ensure that SELinux > > is properly updated. > > > > Signed-off-by: Stephen Smalley <sds@xxxxxxxxxxxxx> > > > > --- > > > > security/selinux/hooks.c | 21 +++++++++++++++++++-- > > security/selinux/include/av_perm_to_string.h | 3 +++ > > security/selinux/include/av_permissions.h | 3 +++ > > security/selinux/include/class_to_string.h | 1 + > > security/selinux/include/flask.h | 1 + > > 5 files changed, 27 insertions(+), 2 deletions(-) > > > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > > index e5ed075..ed5b69f 100644 > > --- a/security/selinux/hooks.c > > +++ b/security/selinux/hooks.c > > @@ -1272,12 +1272,18 @@ static int task_has_perm(struct task_struct *tsk1, > > SECCLASS_PROCESS, perms, NULL); > > } > > > > +#if CAP_LAST_CAP > 63 > > +#error Fix SELinux to handle capabilities > 63. > > +#endif > > I suppose it would be going too far to do something like: > > #define SELINUX_LAST_CAP CAPABILITY2__MAC_ADMIN > > #if (CAP_TO_INDEX(CAP_LAST_CAP) > 2) || (CAP_TO_MASK(CAP_LAST_CAP) > SELINUX_LAST_CAP) > #warning Please teach selinux about capabilities between SELINUX_LAST_CAP+SECCLASS_CAPABILITY2 and CAP_LAST_CAP. > #endif > > ? I don't think it is necessary, although adding a comment to capability.h where it defines CAP_LAST_CAP to notify linux-security-module@xxxxxxxxxxxxxxx of additions would be reasonable as a separate and independent patch from this one. If someone does add a capability < 63 w/o updating SELinux, then what will happen with the current code is that either: a) SELinux will allow it due to the handle_unknown support in Fedora 8 and later, or b) SELinux will deny it (or at least log a denial, if permissive) and avc_audit will report the hex value of the mask along with the capability value in the logs. Neither of which will trip the BUG() case. I only wanted the build failure to catch the BUG() case up front for mainline, and then the BUG() case can only fire upon a real kernel bug and/or an out-of-tree kernel module that is introducing its own private capability definitions. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
