Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation
On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: Eric == Eric Paris epa...@redhat.com writes: So what happens when I create a file /home/john/shadow, does selinux (or LSM in general) then run extra checks because the filename is 'shadow' in your model? It's entirely a question of labeling and one that was discussed on the LSM list in some detail: http://marc.info/?t=12914130822r=1w=2 The basic synopsis is that when a new inode is created SELinux must apply some label. It makes the decision for what label to apply based on 3 pieces of information. The label of the parent inode. The label of the process creating the new inode. The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc This patch adds a 4th piece of information, the name of the object being created. An obvious situation where this will be useful is devtmpfs (although you'll find other examples in the above thread). devtmpfs when it creates char/block devices is unable to distinguish between kmem and console and so they are created with a generic label. hotplug/udev is then called which does some pathname like matching and relabels them to something more specific. We've found that many people are able to race against this particular updating and get spurious denials in /dev. With this patch devtmpfs will be able to get the labels correct to begin with. I'm certainly willing to discuss the security implications of this patch, but that would probably be best done with a significantly shortened cc-list. You'll see in the above mentioned thread that a number of 'security' people (even those who are staunchly anti-SELinux) recognize there is value in this and that it is certainly much better than we have today. I *think* the overhead shouldn't be there if SELINUX is disabled, but have you confirmed this? How you run performance tests before/after this change when doing lots of creations of inodes to see what sort of performance changes might be there? I've actually recently done some perf testing on creating large numbers of inodes using bonnie++, since SELinux was a noticeable overhead in that operation. Doing that same test with SELinux disabled (or enabled) I do not see a noticeable difference when this patch is applied or not. It's just an extra argument to a function that goes unused. -Eric -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation
On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: Eric == Eric Paris epa...@redhat.com writes: Eric On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: Eric == Eric Paris epa...@redhat.com writes: Eric This patch adds a 4th piece of information, the name of the Eric object being created. An obvious situation where this will be Eric useful is devtmpfs (although you'll find other examples in the Eric above thread). devtmpfs when it creates char/block devices is Eric unable to distinguish between kmem and console and so they are Eric created with a generic label. hotplug/udev is then called which Eric does some pathname like matching and relabels them to something Eric more specific. We've found that many people are able to race Eric against this particular updating and get spurious denials in Eric /dev. With this patch devtmpfs will be able to get the labels Eric correct to begin with. So your Label based access controls are *also* based on pathnames? Right? Access decisions are still based solely on the label. This patch can influence how new objects get their label, which makes the access decisions indirectly path based. You'll find a reasonable summary and commentary on lwn in this weeks security section. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fs/vfs/security: pass last path component to LSM on inode creation
SELinux would like to implement a new labeling behavior of newly created
inodes. We currently label new inodes based on the parent and the creating
process. This new behavior would also take into account the name of the
new object when deciding the new label. This is not the (supposed) full path,
just the last component of the path.
This is very useful because creating /etc/shadow is different than creating
/etc/passwd but the kernel hooks are unable to differentiate these
operations. We currently require that userspace realize it is doing some
difficult operation like that and than userspace jumps through SELinux hoops
to get things set up correctly. This patch does not implement new
behavior, that is obviously contained in a seperate SELinux patch, but it
does pass the needed name down to the correct LSM hook. If no such name
exists it is fine to pass NULL.
Signed-off-by: Eric Paris epa...@redhat.com
---
fs/btrfs/inode.c | 13 +++--
fs/btrfs/xattr.c |6 --
fs/btrfs/xattr.h |3 ++-
fs/ext2/ext2.h |2 +-
fs/ext2/ialloc.c |5 +++--
fs/ext2/namei.c|8
fs/ext2/xattr.h|6 --
fs/ext2/xattr_security.c |5 +++--
fs/ext3/ialloc.c |5 +++--
fs/ext3/namei.c|8
fs/ext3/xattr.h|4 ++--
fs/ext3/xattr_security.c |5 +++--
fs/ext4/ialloc.c |2 +-
fs/ext4/xattr.h|4 ++--
fs/ext4/xattr_security.c |5 +++--
fs/gfs2/inode.c|7 ---
fs/jffs2/dir.c |9 -
fs/jffs2/nodelist.h|2 +-
fs/jffs2/security.c|5 +++--
fs/jffs2/write.c | 18 ++
fs/jffs2/xattr.h |5 +++--
fs/jfs/jfs_xattr.h |5 +++--
fs/jfs/namei.c |8
fs/jfs/xattr.c |6 --
fs/ocfs2/namei.c |4 ++--
fs/ocfs2/refcounttree.c|3 ++-
fs/ocfs2/xattr.c | 10 ++
fs/ocfs2/xattr.h |4 +++-
fs/reiserfs/namei.c|9 +
fs/reiserfs/xattr_security.c |3 ++-
fs/xfs/linux-2.6/xfs_iops.c|9 +
include/linux/ext3_fs.h|3 ++-
include/linux/reiserfs_xattr.h |2 ++
include/linux/security.h |9 +++--
mm/shmem.c |9 +
security/capability.c |3 ++-
security/security.c|6 --
security/selinux/hooks.c |5 +++--
security/smack/smack_lsm.c |5 -
39 files changed, 136 insertions(+), 94 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 8039390..ffc6e15 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -90,13 +90,14 @@ static noinline int cow_file_range(struct inode *inode,
unsigned long *nr_written, int unlock);
static int btrfs_init_inode_security(struct btrfs_trans_handle *trans,
-struct inode *inode, struct inode *dir)
+struct inode *inode, struct inode *dir,
+const struct qstr *qstr)
{
int err;
err = btrfs_init_acl(trans, inode, dir);
if (!err)
- err = btrfs_xattr_security_init(trans, inode, dir);
+ err = btrfs_xattr_security_init(trans, inode, dir, qstr);
return err;
}
@@ -4675,7 +4676,7 @@ static int btrfs_mknod(struct inode *dir, struct dentry
*dentry,
if (IS_ERR(inode))
goto out_unlock;
- err = btrfs_init_inode_security(trans, inode, dir);
+ err = btrfs_init_inode_security(trans, inode, dir, dentry-d_name);
if (err) {
drop_inode = 1;
goto out_unlock;
@@ -4736,7 +4737,7 @@ static int btrfs_create(struct inode *dir, struct dentry
*dentry,
if (IS_ERR(inode))
goto out_unlock;
- err = btrfs_init_inode_security(trans, inode, dir);
+ err = btrfs_init_inode_security(trans, inode, dir, dentry-d_name);
if (err) {
drop_inode = 1;
goto out_unlock;
@@ -4864,7 +4865,7 @@ static int btrfs_mkdir(struct inode *dir, struct dentry
*dentry, int mode)
drop_on_err = 1;
- err = btrfs_init_inode_security(trans, inode, dir);
+ err = btrfs_init_inode_security(trans, inode, dir, dentry-d_name);
if (err)
goto out_fail;
@@ -6940,7 +6941,7 @@ static int btrfs_symlink(struct inode *dir, struct dentry
*dentry,
if (IS_ERR(inode))
goto out_unlock;
- err = btrfs_init_inode_security(trans, inode, dir);
+ err = btrfs_init_inode_security(trans, inode, dir, dentry-d_name);
if (err) {
drop_inode = 1
Re: [PATCH] btrfs: use RB_ROOT to intialize rb_trees instead of setting rb_node to NULL
On Tue, 2010-02-23 at 11:51 -0800, Pallipadi, Venkatesh wrote: Acked-by: Venkatesh Pallipadi venkatesh.pallip...@intel.com Quick grep also shows similar initializations in jffs2, ext4 and ext3. Let me know if you already have patch for them, otherwise I can send in the fix for those. I do not, so I think it would be best if you sent in fixes for them. -Eric Thanks, Venki On Tue, 2010-02-23 at 11:43 -0800, Eric Paris wrote: btrfs inialize rb trees in quite a number of places by settin rb_node = NULL; The problem with this is that 17d9ddc72fb8bba0d4f678 in the linux-next tree adds a new field to that struct which needs to be NULL for the new rbtree library code to work properly. This patch uses RB_ROOT as the intializer so all of the relevant fields will be NULL'd. Without the patch I get a panic like that shown below and after the patch my system boots. [5.314627] general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC [5.315518] last sysfs file: /sys/kernel/uevent_seqnum [5.315518] CPU 0 [5.315518] Modules linked in: [last unloaded: scsi_wait_scan] [5.315518] [5.315518] Pid: 1314, comm: mount Not tainted 2.6.33-rc8-next-20100223+ #21 /KVM [5.315518] RIP: 0010:[81296cc0] [81296cc0] rb_insert_color+0x20/0x120 [5.315518] RSP: 0018:88003cc21a88 EFLAGS: 00010206 [5.315518] RAX: 5a5a5a5a5a5a5a5a RBX: ead5e5b8 RCX: [5.315518] RDX: 88003d710080 RSI: 88003d710080 RDI: 88003d610058 [5.315518] RBP: 88003cc21ab8 R08: 0002 R09: [5.315518] R10: R11: 0001 R12: 88003d710070 [5.315518] R13: 0010 R14: 88003d610058 R15: 88003d710080 [5.315518] FS: 7ffe37b197e0() GS:88000400() knlGS: [5.315518] CS: 0010 DS: ES: CR0: 8005003b [5.315518] CR2: 7ffe36d7d010 CR3: 3cd94000 CR4: 06f0 [5.315518] DR0: DR1: DR2: [5.315518] DR3: DR6: 0ff0 DR7: 0400 [5.315518] Process mount (pid: 1314, threadinfo 88003cc2, task 88003d10) [5.315518] Stack: [5.315518] 88003cc21ab8 ead5e5b8 88003d710070 0010 [5.315518] 0 88003d7100e0 0001 88003cc21b48 812058b4 [5.315518] 0 88003cc2e060 88003cc2 0010 00503cc2dff0 [5.315518] Call Trace: [5.315518] [812058b4] alloc_extent_buffer+0x294/0x410 [5.315518] [811dfa28] btrfs_find_create_tree_block+0x28/0x30 [5.315518] [81209cd1] btrfs_read_sys_array+0x31/0x150 [5.315518] [811e429a] open_ctree+0x109a/0x1710 [5.315518] [81133bc5] ? sget+0x365/0x480 [5.315518] [812980af] ? strlcpy+0x4f/0x70 [5.315518] [811c4f8c] btrfs_get_sb+0x41c/0x510 [5.315518] [8114a846] ? alloc_vfsmnt+0xc6/0x1a0 [5.315518] [81133249] vfs_kern_mount+0x89/0x1a0 [5.315518] [811333ce] do_kern_mount+0x4e/0x110 [5.315518] [8114cb47] do_mount+0x547/0x800 [5.315518] [810fe660] ? strndup_user+0x80/0xb0 [5.315518] [8114ce8a] sys_mount+0x8a/0xd0 [5.315518] [8100ae02] system_call_fastpath+0x16/0x1b Signed-off-by: Eric Paris epa...@redhat.com --- fs/btrfs/disk-io.c |4 ++-- fs/btrfs/extent_io.c|4 ++-- fs/btrfs/extent_map.c |2 +- fs/btrfs/free-space-cache.c |4 ++-- fs/btrfs/ordered-data.h |2 +- fs/btrfs/ref-cache.h|2 +- fs/btrfs/relocation.c |4 ++-- fs/btrfs/transaction.c |2 +- 8 files changed, 12 insertions(+), 12 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 2b59201..0427183 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -901,7 +901,7 @@ static int __setup_root(u32 nodesize, u32 leafsize, u32 sectorsize, root-highest_objectid = 0; root-name = NULL; root-in_sysfs = 0; - root-inode_tree.rb_node = NULL; + root-inode_tree = RB_ROOT; INIT_LIST_HEAD(root-dirty_list); INIT_LIST_HEAD(root-orphan_list); @@ -1673,7 +1673,7 @@ struct btrfs_root *open_ctree(struct super_block *sb, insert_inode_hash(fs_info-btree_inode); spin_lock_init(fs_info-block_group_cache_lock); - fs_info-block_group_cache_tree.rb_node = NULL; + fs_info-block_group_cache_tree = RB_ROOT; extent_io_tree_init(fs_info-freed_extents[0], fs_info-btree_inode-i_mapping, GFP_NOFS); diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index b177ed3..7073cbb 100644 --- a/fs/btrfs
btrfs: introduce btrfs_show_options
btrfs options can change at times other than mount, yet /proc/mounts shows the
options string used when the fs was mounted (an example would be when btrfs
determines that barriers aren't useful and turns them off.) This patch
instead outputs the actual options in use by btrfs.
Signed-off-by: Eric Paris epa...@redhat.com
---
fs/btrfs/super.c | 34 +-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 19a4daf..2ceb40b 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -24,6 +24,7 @@
#include linux/highmem.h
#include linux/time.h
#include linux/init.h
+#include linux/seq_file.h
#include linux/string.h
#include linux/smp_lock.h
#include linux/backing-dev.h
@@ -385,6 +386,37 @@ int btrfs_sync_fs(struct super_block *sb, int wait)
return ret;
}
+static int btrfs_show_options(struct seq_file *seq, struct vfsmount *vfs)
+{
+ struct btrfs_root *root = btrfs_sb(vfs-mnt_sb);
+ struct btrfs_fs_info *info = root-fs_info;
+
+ if (btrfs_test_opt(root, DEGRADED))
+ seq_puts(seq, ,degraded);
+ if (btrfs_test_opt(root, NODATASUM))
+ seq_puts(seq, ,nodatasum);
+ if (btrfs_test_opt(root, NODATACOW))
+ seq_puts(seq, ,nodatacow);
+ if (btrfs_test_opt(root, NOBARRIER))
+ seq_puts(seq, ,nobarrier);
+ if (info-max_extent != (u64)-1)
+ seq_printf(seq, ,max_extent=%llu, info-max_extent);
+ if (info-max_inline != 8192 * 1024)
+ seq_printf(seq, ,max_inline=%llu, info-max_inline);
+ if (info-alloc_start != 0)
+ seq_printf(seq, ,alloc_start=%llu, info-alloc_start);
+ if (info-thread_pool_size != min_t(unsigned long,
+num_online_cpus() + 2, 8))
+ seq_printf(seq, ,thread_pool=%d, info-thread_pool_size);
+ if (btrfs_test_opt(root, COMPRESS))
+ seq_puts(seq, ,compress);
+ if (btrfs_test_opt(root, SSD))
+ seq_puts(seq, ,ssd);
+ if (!(root-fs_info-sb-s_flags MS_POSIXACL))
+ seq_puts(seq, ,noacl);
+ return 0;
+}
+
static void btrfs_write_super(struct super_block *sb)
{
sb-s_dirt = 0;
@@ -630,7 +662,7 @@ static struct super_operations btrfs_super_ops = {
.put_super = btrfs_put_super,
.write_super= btrfs_write_super,
.sync_fs= btrfs_sync_fs,
- .show_options = generic_show_options,
+ .show_options = btrfs_show_options,
.write_inode= btrfs_write_inode,
.dirty_inode= btrfs_dirty_inode,
.alloc_inode= btrfs_alloc_inode,
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
