public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David P. Quigley" <dpquigl@tycho.nsa.gov>
To: Greg KH <gregkh@suse.de>
Cc: jmorris@namei.org, sds@tycho.nsa.gov,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks.
Date: Thu, 09 Jul 2009 16:19:45 -0400	[thread overview]
Message-ID: <1247170786.4398.242.camel@localhost> (raw)
In-Reply-To: <20090709201257.GB27124@suse.de>

On Thu, 2009-07-09 at 13:12 -0700, Greg KH wrote:
> On Thu, Jul 09, 2009 at 03:28:58PM -0400, David P. Quigley wrote:
> > On Thu, 2009-07-09 at 10:52 -0700, Greg KH wrote:
> > > On Thu, Jul 09, 2009 at 01:13:33PM -0400, David P. Quigley wrote:
> > > > The issue is that there really aren't any LSM hooks to accommodate that.
> > > > I have a few LSM hooks for the Labeled NFS work which could be used for
> > > > this but it still requires us to store the full xattr value somewhere
> > > > and referencing it in the sysfs_dirent structure.
> > > 
> > > A void pointer would handle that properly, right?
> > 
> > A void pointer would suffice if we wanted to store the opaque blob. My
> > argument is that storing that blob is too heavy weight memory wise.
> 
> You could use that void pointer to store your id with no memory
> difference at all, so why would it be "heavy weight"?  It shoud be
> identical, right?
> 
> thanks,
> 
> greg k-h


Not quite. From the memory foot print inside sysfs_dirent it is the same
(baring a pointer being 64-bit on certain platforms) however that
pointer needs to be backed by something. The two current interfaces in
LSM to set an inode security attribute is 1) the xattr, and 2) a secid.
The issue is if we say some people can store the xattr and some can
store a secid I then don't know what hook to call to set the security
information on creation. Which basically boils down to if we have a void
* in sysfs_dirent it has to be the same void * semantics already used
which means it needs to have a string with the label backing it. This
means in the SELinux case I'm now using memory for the string and the
structure in the security server which is a waste. It seems to me though
that It might be possible to make the size of the secid correspond to
the size of a pointer so Casey can return the address of his string as
the secid and we can return the secid. However, it still needs to have
the semantics of the secid and not the opaque void *. 

I could be wrong about this but at the moment the mismatch of semantics
between the two seem to be a problem. If I'm missing anything feel free
to point it out.


  reply	other threads:[~2009-07-09 20:29 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-08 17:28 [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2009-07-15 13:48 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
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-20 13:18 ` David P. Quigley
2009-08-21  3:38   ` Casey Schaufler
2009-09-03 18:25 David P. Quigley

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=1247170786.4398.242.camel@localhost \
    --to=dpquigl@tycho.nsa.gov \
    --cc=gregkh@suse.de \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@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