Re: Dealing with 64-bit capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Stephen Smalley (sds@xxxxxxxxxxxxx):
> On Tue, 2007-10-16 at 14:34 -0500, Serge E. Hallyn wrote:
> > Quoting Stephen Smalley (sds@xxxxxxxxxxxxx):
> > > Given that Serge has put out a RFC patch on lsm and lkml for extending
> > > capabilities to 64 bits, we should likely finalize how we want to handle
> > > them in SELinux.
> > > 
> > > Extending the access vector to 64-bits isn't a good idea IMHO, as it
> > > will waste quite a bit of space throughout the AVC and the security
> > > server policydb.
> > > 
> > > In the past we've talked about introducing a second capability class and
> > > access vector for the higher 32 capabilities, and optionally providing
> > > syntactic sugar in checkpolicy so the user doesn't have to think about
> > > it as two separate classes.
> > > 
> > > Possible kernel patch below to define the new class and change
> > > task_has_capability to use it for the higher capabilities.  Comments?
> > 
> > Looks reasonable.  Note that if STRICT_CAP_T_TYPECHECKS were
> > set your use of kernel_cap_t would trigger errors.  near as
> > I can tell that isn't ever done, but still to get around that
> > you'd just do
> 
> Ok..I didn't bother originally because the kernel doesn't build with
> that defined (I did try it) - there is at least one fatal error over in
> the nfsd code and warnings even from the capability code.

I'd wondered about that :)

Judging by
http://www.uwsg.iu.edu/hypermail/linux/kernel/9810.2/0705.html,
the option was actually introduced in 1998 because the use of
the struct was broken.  Given that, are there any objections to the
following patch?

thanks,
-serge


>From 141626df6eaba12f5566f6bce7e72c1c3e627364 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@xxxxxxxxxx>
Date: Wed, 17 Oct 2007 10:00:49 -0400
Subject: [PATCH 1/1] capabilities: remove STRICT_CAP_T_TYPECHECKS

It appears STRICT_CAP_T_TYPECHECKS was introduced in 1998 - and
always undefined since then - because the STRICT_CAP_T_TYPECHECKS
behavior is broken.  (See http://www.uwsg.iu.edu/hypermail/linux/kernel/9810.2/0705.html)

Remove this code to simplify the capabilites code.

Signed-off-by: Serge E. Hallyn <serue@xxxxxxxxxx>
---
 include/linux/capability.h |   21 ---------------------
 1 files changed, 0 insertions(+), 21 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 7a8d7ad..8f7c7ed 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -64,20 +64,8 @@ struct vfs_cap_data {
 
 #ifdef __KERNEL__
 
-/* #define STRICT_CAP_T_TYPECHECKS */
-
-#ifdef STRICT_CAP_T_TYPECHECKS
-
-typedef struct kernel_cap_struct {
-	__u32 cap;
-} kernel_cap_t;
-
-#else
-
 typedef __u32 kernel_cap_t;
 
-#endif
-
 #define _USER_CAP_HEADER_SIZE  (2*sizeof(__u32))
 #define _KERNEL_CAP_T_SIZE     (sizeof(kernel_cap_t))
 
@@ -315,18 +303,9 @@ typedef __u32 kernel_cap_t;
  * Internal kernel functions only
  */
 
-#ifdef STRICT_CAP_T_TYPECHECKS
-
-#define to_cap_t(x) { x }
-#define cap_t(x) (x).cap
-
-#else
-
 #define to_cap_t(x) (x)
 #define cap_t(x) (x)
 
-#endif
-
 #define CAP_EMPTY_SET       to_cap_t(0)
 #define CAP_FULL_SET        to_cap_t(~0)
 #define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
-- 
1.5.1.1.GIT


--
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.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux