| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20071016184818.GA17755@vino.hallyn.com>
Date: Tue, 16 Oct 2007 13:48:18 -0500
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Stephen Smalley <sds@...ho.nsa.gov>
Cc: "Serge E. Hallyn" <serue@...ibm.com>,
linux-security-module@...r.kernel.org,
Andrew Morton <akpm@...l.org>,
Andrew Morgan <morgan@...nel.org>,
Chris Wright <chrisw@...s-sol.org>,
lkml <linux-kernel@...r.kernel.org>,
KaiGai Kohei <kaigai@...gai.gr.jp>,
Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
Quoting Stephen Smalley (sds@...ho.nsa.gov):
> On Mon, 2007-10-15 at 21:31 -0500, Serge E. Hallyn wrote:
> > >From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001
> > From: Serge E. Hallyn <serue@...ibm.com>
> > Date: Mon, 15 Oct 2007 20:57:52 -0400
> > Subject: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
> >
> > We are out of capabilities in the 32-bit capability fields, and
> > several users could make use of additional capabilities.
> > Convert the capabilities to 64-bits, change the capability
> > version number accordingly, and convert the file capability
> > code to handle both 32-bit and 64-bit file capability xattrs.
> >
> > It might seem desirable to also implement back-compatibility
> > to read 32-bit caps from userspace, but that becomes
> > problematic with capget, as capget could return valid info
> > for processes not using high bits, but would have to return
> > -EINVAL for those which were.
> >
> > So with this patch, libcap would need to be updated to make
> > use of capset/capget.
> >
> > Signed-off-by: Serge E. Hallyn <serue@...ibm.com>
> > ---
> > fs/proc/array.c | 6 +++---
> > include/linux/capability.h | 29 ++++++++++++++++++++---------
> > security/commoncap.c | 37 +++++++++++++++++++++++++++++--------
> > 3 files changed, 52 insertions(+), 20 deletions(-)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index 3f4d824..c8ea46d 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -288,9 +288,9 @@ static inline char *task_sig(struct task_struct *p, char *buffer)
> >
> > static inline char *task_cap(struct task_struct *p, char *buffer)
> > {
> > - return buffer + sprintf(buffer, "CapInh:\t%016x\n"
> > - "CapPrm:\t%016x\n"
> > - "CapEff:\t%016x\n",
> > + return buffer + sprintf(buffer, "CapInh:\t%016lx\n"
> > + "CapPrm:\t%016lx\n"
> > + "CapEff:\t%016lx\n",
> > cap_t(p->cap_inheritable),
> > cap_t(p->cap_permitted),
> > cap_t(p->cap_effective));
> > diff --git a/include/linux/capability.h b/include/linux/capability.h
> > index bb017ed..a3da4b9 100644
> > --- a/include/linux/capability.h
> > +++ b/include/linux/capability.h
> > @@ -29,7 +29,7 @@ struct task_struct;
> > library since the draft standard requires the use of malloc/free
> > etc.. */
> >
> > -#define _LINUX_CAPABILITY_VERSION 0x19980330
> > +#define _LINUX_CAPABILITY_VERSION 0x20071015
> >
> > typedef struct __user_cap_header_struct {
> > __u32 version;
> > @@ -37,29 +37,40 @@ typedef struct __user_cap_header_struct {
> > } __user *cap_user_header_t;
> >
> > typedef struct __user_cap_data_struct {
> > - __u32 effective;
> > - __u32 permitted;
> > - __u32 inheritable;
> > + __u64 effective;
> > + __u64 permitted;
> > + __u64 inheritable;
> > } __user *cap_user_data_t;
> >
> > #define XATTR_CAPS_SUFFIX "capability"
> > #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
> >
> > -#define XATTR_CAPS_SZ (3*sizeof(__le32))
> > +#define XATTR_CAPS_SZ_1 (3*sizeof(__le32))
> > +#define XATTR_CAPS_SZ_2 (2*sizeof(__le64) + sizeof(__le32))
> > #define VFS_CAP_REVISION_MASK 0xFF000000
> > #define VFS_CAP_REVISION_1 0x01000000
> > +#define VFS_CAP_REVISION_2 0x02000000
> >
> > -#define VFS_CAP_REVISION VFS_CAP_REVISION_1
> > +#define VFS_CAP_REVISION VFS_CAP_REVISION_2
> > +#define XATTR_CAPS_SZ XATTR_CAPS_SZ_2
> >
> > #define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
> > #define VFS_CAP_FLAGS_EFFECTIVE 0x000001
> >
> > -struct vfs_cap_data {
> > +struct vfs_cap_data_v1 {
> > __u32 magic_etc; /* Little endian */
> > __u32 permitted; /* Little endian */
> > __u32 inheritable; /* Little endian */
> > };
> >
> > +struct vfs_cap_data_v2 {
> > + __u32 magic_etc; /* Little endian */
> > + __u64 permitted; /* Little endian */
> > + __u64 inheritable; /* Little endian */
> > +};
> > +
> > +typedef struct vfs_cap_data_v2 vfs_cap_data;
> > +
> > #ifdef __KERNEL__
> >
> > /* #define STRICT_CAP_T_TYPECHECKS */
> > @@ -67,12 +78,12 @@ struct vfs_cap_data {
> > #ifdef STRICT_CAP_T_TYPECHECKS
> >
> > typedef struct kernel_cap_struct {
> > - __u32 cap;
> > + __u64 cap;
> > } kernel_cap_t;
> >
> > #else
> >
> > -typedef __u32 kernel_cap_t;
> > +typedef __u64 kernel_cap_t;
> >
> > #endif
>
> Don't you need to update CAP_TO_MASK() too?
Yeah, I'm afraid so.
> And, of course, SELinux task_has_capability() will then need to deal
> with higher capabilities differently, most likely by mapping them to
> permissions in a new class and access vector.
I saw your other email about this so will watch that thread.
thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists