From: Casey Schaufler <casey@schaufler-ca.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: "David P. Quigley" <dpquigl@tycho.nsa.gov>,
jmorris@namei.org, Greg Kroah-Hartman <greg@kroah.com>,
ebiederm@xmission.com, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov
Subject: Re: [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks.
Date: Fri, 14 Aug 2009 18:33:16 -0700 [thread overview]
Message-ID: <4A86105C.4070806@schaufler-ca.com> (raw)
In-Reply-To: <1250253651.2422.183.camel@moss-pluto.epoch.ncsc.mil>
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.
>>> +
>>> + return nxattr;
>>> +}
>>> +
>>> +int sysfs_setxattr(struct dentry *dentry, const char *name,
>>> + const void *value, size_t size, int flags)
>>> +{
>>> + struct sysfs_dirent *sd = dentry->d_fsdata;
>>> + struct list_head *xlist;
>>> + struct sysfs_xattr *nxattr;
>>> + void *nvalue;
>>> + int rc = 0;
>>> +
>>> + /*
>>> + * Only support the security namespace.
>>> + * Only allow privileged processes to set them.
>>> + * It has to be OK with the LSM, if any, as well.
>>> + */
>>> + if (strncmp(name, XATTR_SECURITY_PREFIX,
>>> + sizeof XATTR_SECURITY_PREFIX - 1))
>>> + return -ENOTSUPP;
>>> +
>>> + if (!capable(CAP_SYS_ADMIN))
>>> + return -EPERM;
>>>
>> SELinux does not require CAP_SYS_ADMIN to set its attributes, so this
>> breaks its security model.
>>
>
> And you don't need to apply any permission check here, as it gets
> covered by the security_inode_setxattr() hook in vfs_setxattr() prior to
> invoking i_op->setxattr.
>
David seemed to think it necessary in an earlier review. I will
have another look.
next prev parent reply other threads:[~2009-08-15 1:35 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-15 13:48 [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks David P. Quigley
2009-07-15 14:28 ` David P. Quigley
2009-07-15 14:31 ` David P. Quigley
2009-07-21 16:29 ` David P. Quigley
2009-07-21 16:49 ` Greg KH
2009-07-21 16:34 ` David P. Quigley
2009-07-21 17:01 ` David P. Quigley
2009-07-24 8:13 ` James Morris
2009-07-24 14:34 ` David P. Quigley
2009-07-24 14:54 ` Casey Schaufler
2009-08-14 4:59 ` Casey Schaufler
2009-08-14 12:20 ` Stephen Smalley
2009-08-14 12:40 ` Stephen Smalley
2009-08-15 1:33 ` Casey Schaufler [this message]
2009-08-17 12:01 ` Stephen Smalley
2009-08-15 1:19 ` Casey Schaufler
2009-08-17 11:53 ` Stephen Smalley
2009-08-14 22:02 ` Eric W. Biederman
2009-08-15 1:42 ` Casey Schaufler
2009-08-15 2:15 ` Eric W. Biederman
2009-08-15 4:56 ` Casey Schaufler
2009-08-15 6:01 ` Eric W. Biederman
2009-08-16 17:25 ` Casey Schaufler
2009-08-18 3:55 ` [PATCH] Security/sysfs: v2 - " Casey Schaufler
2009-08-18 12:14 ` Stephen Smalley
2009-08-18 14:12 ` Casey Schaufler
2009-08-18 14:23 ` Stephen Smalley
2009-08-19 4:37 ` Casey Schaufler
2009-08-19 11:58 ` Stephen Smalley
2009-08-19 17:47 ` Casey Schaufler
2009-08-19 23:59 ` Casey Schaufler
2009-08-20 2:41 ` Eric W. Biederman
2009-08-20 11:53 ` Stephen Smalley
2009-08-20 13:18 ` [PATCH] Security/sysfs: " David P. Quigley
2009-08-21 3:38 ` Casey Schaufler
-- strict thread matches above, loose matches on Subject: below --
2009-09-03 18:25 David P. Quigley
2009-07-08 17:28 David P. Quigley
2009-07-09 1:44 ` Casey Schaufler
2009-07-09 14:05 ` David P. Quigley
2009-07-09 14:49 ` Casey Schaufler
2009-07-09 14:56 ` David P. Quigley
2009-07-09 15:16 ` David P. Quigley
2009-07-09 15:16 ` Greg KH
2009-07-09 14:11 ` David P. Quigley
2009-07-09 17:26 ` David P. Quigley
2009-07-09 17:50 ` Greg KH
2009-07-09 19:32 ` David P. Quigley
2009-07-09 20:13 ` Greg KH
2009-07-10 3:25 ` Casey Schaufler
2009-07-13 15:07 ` David P. Quigley
2009-07-09 15:18 ` Greg KH
2009-07-09 17:13 ` David P. Quigley
2009-07-09 17:52 ` Greg KH
2009-07-09 19:28 ` David P. Quigley
2009-07-09 20:12 ` Greg KH
2009-07-09 20:19 ` David P. Quigley
2009-07-09 20:41 ` Greg KH
2009-07-14 16:37 ` David P. Quigley
2009-07-14 17:50 ` Greg KH
2009-07-14 20:16 ` David P. Quigley
2009-07-14 20:35 ` Greg KH
2009-07-14 20:35 ` David P. Quigley
[not found] ` <m1r5wmnee0.fsf@fess.ebiederm.org>
[not found] ` <1247498399.4398.259.camel@localhost>
2009-07-13 16:50 ` Eric W. Biederman
2009-07-13 19:18 ` David P. Quigley
2009-07-14 0:29 ` Eric W. Biederman
2009-07-14 13:55 ` David P. Quigley
2009-07-14 3:06 ` Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A86105C.4070806@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=dpquigl@tycho.nsa.gov \
--cc=ebiederm@xmission.com \
--cc=greg@kroah.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox