lkml.org 
[lkml]   [2009]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks.
From
Date
On Fri, 2009-08-14 at 18:33 -0700, Casey Schaufler wrote:
> Stephen Smalley wrote:
> > On Fri, 2009-08-14 at 08:20 -0400, Stephen Smalley wrote:
> >
> >> ...
> >>> + */
> >>> +static DEFINE_MUTEX(sysfs_xattr_lock);
> >>> +
> >>> +static struct sysfs_xattr *new_xattr(const char *name, const void *value,
> >>> + size_t size)
> >>> +{
> >>> + struct sysfs_xattr *nxattr;
> >>> + void *nvalue;
> >>> + char *nname;
> >>> +
> >>> + nxattr = kzalloc(sizeof(*nxattr), GFP_KERNEL);
> >>> + if (!nxattr)
> >>> + return NULL;
> >>> + nvalue = kzalloc(size, GFP_KERNEL);
> >>> + if (!nvalue) {
> >>> + kfree(nxattr);
> >>> + return NULL;
> >>> + }
> >>> + nname = kzalloc(strlen(name) + 1, GFP_KERNEL);
> >>> + if (!nname) {
> >>> + kfree(nxattr);
> >>> + kfree(nvalue);
> >>> + return NULL;
> >>> + }
> >>> + memcpy(nvalue, value, size);
> >>> + strcpy(nname, name);
> >>> + nxattr->sx_name = nname;
> >>> + nxattr->sx_value = nvalue;
> >>> + nxattr->sx_size = size;
> >>>
> >> Storing the name/value pairs here is redundant - the security module
> >> already has to store the value in some form (potentially smaller, like a
> >> secid + struct in the SELinux case). This wastes memory.
> >>
> >
> > Sorry - to clarify, I understand that we have to store a representation
> > of the security attribute in the backing data structure so that it can
> > be restored later, but that representation should come from the security
> > module rather than being the original (name, value, size) triple. Which
> > is what David's patch does - he obtains a secid from the security module
> > for storage in the wrapped iattr structure.
> >
>
> Sorry, but I disagree with your assertion. An LSM can do what
> it likes with the xattr, but the value sent from userland is
> what should be stored.

Then you will definitely end up using more memory than David's approach,
as in the Smack case you'll duplicate storage of the text string by both
the filesystem and by the security module, and in the SELinux case the
filesystem will store the full text string and SELinux will store the
struct representation (full string representation is generated on
demand).

--
Stephen Smalley
National Security Agency



\
 
 \ /
  Last update: 2009-08-17 14:01    [W:0.084 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site