From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "David P. Quigley" <dpquigl@tycho.nsa.gov>,
jmorris@namei.org, casey@schaufler-ca.com, gregkh@suse.de,
ebiederm@xmission.com, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH 2/3] LSM/SELinux: inode_{get,set,notify}secctx hooks to access LSM security context information.
Date: Fri, 04 Sep 2009 12:21:54 -0400 [thread overview]
Message-ID: <1252081314.13634.333.camel@moss-pluto.epoch.ncsc.mil> (raw)
In-Reply-To: <20090904154917.GB15342@us.ibm.com>
On Fri, 2009-09-04 at 10:49 -0500, Serge E. Hallyn wrote:
> Quoting David P. Quigley (dpquigl@tycho.nsa.gov):
> > This patch introduces three new hooks. The inode_getsecctx hook is used to get
> > all relevant information from an LSM about an inode. The inode_setsecctx is
>
> The 'security_xyz_getctx' namespace is getting a bit polluted. I suspect
> I should take this as a hint to rename my
> selinux_file_get_ctx()
> to
> selinux_checkpoint_file()
Yes, I think that would be clearer.
> or
> selinux_checkpoint_file_ctx()
>
> to more clearly distinguish it from your hooks and the existing
> secid_to_secctx() set of .hooks
>
> > used to set both the in-core and on-disk state for the inode based on a context
> > derived from inode_getsecctx.The final hook inode_notifysecctx will notify the
> > LSM of a change for the in-core state of the inode in question. These hooks are
> > for use in the labeled NFS code and addresses concerns of how to set security
> > on an inode in a multi-xattr LSM. For historical reasons Stephen Smalley's
> > explanation of the reason for these hooks is pasted below.
> >
> > Quote Stephen Smalley
> >
> > inode_setsecctx: Change the security context of an inode. Updates the
> > in core security context managed by the security module and invokes the
> > fs code as needed (via __vfs_setxattr_noperm) to update any backing
> > xattrs that represent the context. Example usage: NFS server invokes
> > this hook to change the security context in its incore inode and on the
> > backing file system to a value provided by the client on a SETATTR
> > operation.
>
> So this is only to be called by kernel code, right? Hence no
> authorization checks needed?
Correct. And just to clarify, these hooks have been previously
discussed for the labeled NFS work, but were on hold until a user of
them (e.g. the labeled NFS support itself) was ready to upstream. But
they turn out to be useful for sysfs labeling as well since they address
Casey's concerns about not passing secids and supporting multi-xattr
LSMs, so the sysfs patch was reworked to use them.
>
> > inode_notifysecctx: Notify the security module of what the security
> > context of an inode should be. Initializes the incore security context
> > managed by the security module for this inode. Example usage: NFS
> > client invokes this hook to initialize the security context in its
> > incore inode to the value provided by the server for the file when the
> > server returned the file's attributes to the client.
> >
> > Signed-off-by: David P. Quigley <dpquigl@tycho.nsa.gov>
>
> Acked-by: Serge Hallyn <serue@us.ibm.com>
--
Stephen Smalley
National Security Agency
next prev parent reply other threads:[~2009-09-04 16:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 18:25 [PATCH] Security/sysfs: Enable security xattrs to be set on sysfs files, directories, and symlinks David P. Quigley
2009-09-03 18:25 ` [PATCH 1/3] VFS: Factor out part of vfs_setxattr so it can be called from the SELinux hook for inode_setsecctx David P. Quigley
2009-09-04 15:31 ` Serge E. Hallyn
2009-09-03 18:25 ` [PATCH 2/3] LSM/SELinux: inode_{get,set,notify}secctx hooks to access LSM security context information David P. Quigley
2009-09-04 15:49 ` Serge E. Hallyn
2009-09-04 16:21 ` Stephen Smalley [this message]
2009-09-03 18:25 ` [PATCH 3/3] sysfs: Add labeling support for sysfs David P. Quigley
2009-09-04 16:03 ` Serge E. Hallyn
2009-09-07 1:48 ` James Morris
2009-09-09 18:25 ` Stephen Smalley
2009-09-10 0:40 ` James Morris
2009-09-10 3:01 ` Greg KH
2009-09-10 3:48 ` Casey Schaufler
2009-09-10 12:14 ` Stephen Smalley
2009-09-10 10:31 ` James Morris
2009-09-11 4:17 ` Casey Schaufler
2009-09-11 4:25 ` Greg KH
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=1252081314.13634.333.camel@moss-pluto.epoch.ncsc.mil \
--to=sds@tycho.nsa.gov \
--cc=casey@schaufler-ca.com \
--cc=dpquigl@tycho.nsa.gov \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serue@us.ibm.com \
/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
all inboxes | Powered by JetHome®