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 13:13:33 -0400 [thread overview]
Message-ID: <1247159613.4398.215.camel@localhost> (raw)
In-Reply-To: <20090709151803.GB24302@suse.de>
On Thu, 2009-07-09 at 08:18 -0700, Greg KH wrote:
> On Wed, Jul 08, 2009 at 01:28:26PM -0400, David P. Quigley wrote:
> > --- a/fs/sysfs/sysfs.h
> > +++ b/fs/sysfs/sysfs.h
> > @@ -57,6 +57,7 @@ struct sysfs_dirent {
> > ino_t s_ino;
> > umode_t s_mode;
> > struct iattr *s_iattr;
> > + u32 s_secid;
> > };
>
> Why not just make this a void * like all other security hooks, and then
> you and SMACK can pick and choose what you want to embed here?
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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. The issue here is that
there are two ways of presenting security information. The first is
through the xattr interface which represents the security information as
an opaque blob which the LSM turns into an internal representation. The
second which is left over from the early days is the secid which I
equate to a file handle. The problem I see is that the opaque blob (the
xattr) is the interface presented to user space. It isn't really used
internally except to turn it into a data structure or to write it to
disk for persistence.
The situation we have with sysfs is that there is no persistence for
labels and the in-core inode maybe evicted so we need a way of
persisting changes from the default label. What is really need here is
a way of persisting the security structure maintained by the LSM. Since
these structures are contained in the LSM the only reasonable
abstraction for this is for the LSM to provide a handle to refer to the
structure. There are two ways of doing this. One is with a large string
(the xattr) and the other is with a light weight handle (the secid).
Dave
next prev parent reply other threads:[~2009-07-09 17:22 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 [this message]
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
-- 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=1247159613.4398.215.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