From: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Eric Paris <eparis@redhat.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
linux-fsdevel@vger.kernel.org,
David Quigley <dpquigl@davequigley.com>,
"J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-security-module@vger.kernel.org, cluster-devel@redhat.com
Subject: [RFC 00/11] Inode security label invalidation
Date: Thu, 20 Aug 2015 20:19:47 +0200 [thread overview]
Message-ID: <1440094798-1411-1-git-send-email-agruenba@redhat.com> (raw)
Hello,
this patch queue adds an LSM hook for file systems to invalidate inode security
labels. To allow selinux to revalidate invalid labels, the generic xattr
handlers are cleaned up a bit and a new igetxattr inode operation is
introduced: the getxattr inode operation requires a dentry which selinux
doesn't have in inode_has_perm(); igetxattr instead takes an inode. Finally,
gfs2 is patched to make use of this new mechanism.
The new igetxattr inode operation currently is *only* used for revalidating
security labels in selinux; it may make sense to use it instead of getxattr
when defined.
Is this approach useful? An alternative would be to modify selinux so that it
always has a dentry when checking inode security labels; I would guess that
this won't work in all cases, though.
BACKGROUND
Selinux currently assumes that, after initialization, inode->i_security always
represents the current security label of the inode. This assumption works for
local file systems; any change of the label must go through setxattr (or
removexattr) which updates inode->i_security.
On an nfs mount, other nodes can change the security label; there is no
immediate notification mechanism. Other nodes will eventually notice a label
change because the label is transmitted as part of the reply of operations like
open. (A timeout for cached labels would help too; I'm not sure if the code
implements that.)
Other file systems have different consistency models. For example, gfs2 inodes
go "invalid" when a node drops the inode's glocks. When such an invalid inode
is accessed again, all the metadata must be read from disk again, including the
security label.
For that case, the file system has no way of updating the security label before
selinux next uses it. Things also don't fix themselves over time; when selinux
rejects access, the file system never notices.
To fix that, this patch queue adds a mechanism for file systems to invalidate
inode security labels, and for selinux to revalidate them; this is similar to
how the inode acl cache works.
Thanks,
Andreas
Andreas Gruenbacher (11):
ubifs: Remove unused "security.*" xattr handler
hfsplus: Remove unused xattr handler list operations
9p: Simplify the xattr handlers
xattr handlers: Pass handler to operations instead of flags
xattr handlers: Some simplifications
lib: Move strcmp_prefix into string.c
9p: Stop using the generic xattr_handler infrastructure
xattr: Pass inodes to xattr handlers instead of dentries
vfs: Add igetxattr inode operation
selinux: Allow to invalidate an inode's security label
gfs2: Invalide security labels of inodes that go invalid
Documentation/filesystems/Locking | 2 +
Documentation/filesystems/vfs.txt | 4 ++
fs/9p/Makefile | 5 +--
fs/9p/acl.c | 65 ++++++------------------------
fs/9p/vfs_super.c | 5 +--
fs/9p/xattr.c | 74 +++++++++++++++++++++++++++++++++-
fs/9p/xattr.h | 18 ++++++---
fs/9p/xattr_security.c | 80 -------------------------------------
fs/9p/xattr_trusted.c | 80 -------------------------------------
fs/9p/xattr_user.c | 80 -------------------------------------
fs/ext2/xattr.c | 4 +-
fs/ext2/xattr_security.c | 19 +++++----
fs/ext2/xattr_trusted.c | 19 +++++----
fs/ext2/xattr_user.c | 25 ++++++------
fs/ext3/xattr.c | 5 ++-
fs/ext3/xattr_security.c | 19 +++++----
fs/ext3/xattr_trusted.c | 19 +++++----
fs/ext3/xattr_user.c | 25 ++++++------
fs/ext4/xattr.c | 5 ++-
fs/ext4/xattr_security.c | 19 +++++----
fs/ext4/xattr_trusted.c | 19 +++++----
fs/ext4/xattr_user.c | 25 ++++++------
fs/f2fs/xattr.c | 71 +++++++++++++++------------------
fs/gfs2/glops.c | 2 +
fs/gfs2/inode.c | 16 ++++++--
fs/gfs2/xattr.c | 17 ++++----
fs/hfsplus/xattr.c | 33 ++++++----------
fs/hfsplus/xattr.h | 4 +-
fs/hfsplus/xattr_security.c | 25 ++++--------
fs/hfsplus/xattr_trusted.c | 25 ++++--------
fs/hfsplus/xattr_user.c | 25 ++++--------
fs/jffs2/security.c | 19 +++++----
fs/jffs2/xattr.c | 8 ++--
fs/jffs2/xattr_trusted.c | 18 +++++----
fs/jffs2/xattr_user.c | 19 +++++----
fs/nfs/nfs4proc.c | 49 ++++++++++++-----------
fs/ocfs2/xattr.c | 63 ++++++++++++++++-------------
fs/posix_acl.c | 37 ++++++++---------
fs/reiserfs/xattr.c | 29 ++++++++------
fs/reiserfs/xattr_security.c | 24 +++++------
fs/reiserfs/xattr_trusted.c | 24 +++++------
fs/reiserfs/xattr_user.c | 24 +++++------
fs/squashfs/xattr.c | 83 ++++++++++++++-------------------------
fs/ubifs/super.c | 1 -
fs/ubifs/ubifs.h | 1 -
fs/ubifs/xattr.c | 40 -------------------
fs/xattr.c | 37 ++++++++---------
fs/xfs/xfs_xattr.c | 16 +++++---
include/linux/fs.h | 1 +
include/linux/lsm_hooks.h | 6 +++
include/linux/security.h | 5 +++
include/linux/string.h | 1 +
include/linux/xattr.h | 16 ++++----
lib/string.c | 16 ++++++++
security/selinux/hooks.c | 47 ++++++++++++++++------
security/selinux/include/objsec.h | 3 +-
56 files changed, 620 insertions(+), 801 deletions(-)
delete mode 100644 fs/9p/xattr_security.c
delete mode 100644 fs/9p/xattr_trusted.c
delete mode 100644 fs/9p/xattr_user.c
--
2.4.3
next reply other threads:[~2015-08-20 18:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 18:19 Andreas Gruenbacher [this message]
2015-08-20 18:19 ` [RFC 01/11] ubifs: Remove unused "security.*" xattr handler Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 02/11] hfsplus: Remove unused xattr handler list operations Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 03/11] 9p: Simplify the xattr handlers Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 04/11] xattr handlers: Pass handler to operations instead of flags Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 05/11] xattr handlers: Some simplifications Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 06/11] lib: Move strcmp_prefix into string.c Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 07/11] 9p: Stop using the generic xattr_handler infrastructure Andreas Gruenbacher
2015-08-21 6:46 ` Christoph Hellwig
2015-08-21 8:35 ` [Cluster-devel] " Steven Whitehouse
2015-08-20 18:19 ` [RFC 08/11] xattr: Pass inodes to xattr handlers instead of dentries Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 09/11] vfs: Add igetxattr inode operation Andreas Gruenbacher
2015-08-21 6:48 ` Christoph Hellwig
2015-08-20 18:19 ` [RFC 10/11] selinux: Allow to invalidate an inode's security label Andreas Gruenbacher
2015-08-20 18:19 ` [RFC 11/11] gfs2: Invalide security labels of inodes that go invalid Andreas Gruenbacher
2015-08-21 6:49 ` Christoph Hellwig
2015-08-21 9:25 ` [Cluster-devel] " Andreas Gruenbacher
2015-08-24 17:42 ` [RFC 00/11] Inode security label invalidation Stephen Smalley
2015-08-24 19:13 ` Andreas Grünbacher
2015-08-24 20:47 ` Eric Paris
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=1440094798-1411-1-git-send-email-agruenba@redhat.com \
--to=andreas.gruenbacher@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bfields@fieldses.org \
--cc=cluster-devel@redhat.com \
--cc=dpquigl@davequigley.com \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).