Stephen Smalley wrote:
On Wed, 2008-02-06 at 11:22 -0500, Stephen Smalley wrote:
64-bit capability support has gone into mainline.
Update SELinux to correctly handle 64-bit capabilities.
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e5ed075..fa4b021 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1278,6 +1278,8 @@ static int task_has_capability(struct task_struct *tsk,
{
struct task_security_struct *tsec;
struct avc_audit_data ad;
+ u16 sclass;
+ u32 av = CAP_TO_MASK(cap);
tsec = tsk->security;
@@ -1285,8 +1287,17 @@ static int task_has_capability(struct task_struct *tsk,
ad.tsk = tsk;
ad.u.cap = cap;
- return avc_has_perm(tsec->sid, tsec->sid,
- SECCLASS_CAPABILITY, CAP_TO_MASK(cap), &ad);
+ switch (CAP_TO_INDEX(cap)) {
+ case 0:
+ sclass = SECCLASS_CAPABILITY;
+ break;
+ case 1:
+ sclass = SECCLASS_CAPABILITY2;
+ break;
+ default:
+ return -EPERM;
Should likely make this something like:
printk(KERN_WARNING "SELinux: unknown capability %d\n", cap);
if (selinux_enforcing)
return -EPERM;
else
return 0;
Then, if/when people introduce capabilities without updating SELinux,
we'll get a warning but permissive mode will allow the operation to
proceed.
Are we going to do some magic in the toolchain to treat caps as 1 class
in source policy but split it up in binary? I remember that being a
possibility at some point.
--
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.
