Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1271424 > unrolled thread

[PATCH v3 0/7] User namespace mount updates

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 17:50 +0100
    [PATCH v3 1/7] block_dev: Support checking inode permissions in lookup_bdev() Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 17:50 +0100
    [PATCH v3 2/7] block_dev: Check permissions towards block device inode when mounting Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 17:50 +0100
    [PATCH v3 3/7] mtd: Check permissions towards mtd block device inode when mounting Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 17:50 +0100
    Re: [PATCH v3 0/7] User namespace mount updates Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-17 18:10 +0100
      Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 18:30 +0100
        Re: [PATCH v3 0/7] User namespace mount updates "Serge E. Hallyn" <serge@hallyn.com> - 2015-11-17 18:50 +0100
        Re: [PATCH v3 0/7] User namespace mount updates Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-17 19:00 +0100
          Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 19:40 +0100
            Re: [PATCH v3 0/7] User namespace mount updates Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-17 20:20 +0100
              Re: [PATCH v3 0/7] User namespace mount updates Octavian Purdila <octavian.purdila@intel.com> - 2015-11-17 20:30 +0100
                Re: [PATCH v3 0/7] User namespace mount updates Richard Weinberger <richard@nod.at> - 2015-11-17 21:20 +0100
                  Re: [PATCH v3 0/7] User namespace mount updates Octavian Purdila <octavian.purdila@intel.com> - 2015-11-17 23:10 +0100
                    Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-19 16:30 +0100
                      Re: [PATCH v3 0/7] User namespace mount updates Octavian Purdila <octavian.purdila@intel.com> - 2015-11-19 17:20 +0100
                        Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-19 17:40 +0100
                        Re: [PATCH v3 0/7] User namespace mount updates "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2015-11-20 18:40 +0100
              Re: [PATCH v3 0/7] User namespace mount updates Richard Weinberger <richard@nod.at> - 2015-11-17 20:30 +0100
              Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 20:30 +0100
            Re: [PATCH v3 0/7] User namespace mount updates Theodore Ts'o <tytso@mit.edu> - 2015-11-18 20:20 +0100
              Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-18 20:30 +0100
              Re: [PATCH v3 0/7] User namespace mount updates Serge Hallyn <serge.hallyn@ubuntu.com> - 2015-11-18 20:40 +0100
          Re: [PATCH v3 0/7] User namespace mount updates Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-17 20:10 +0100
            Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 20:20 +0100
              Re: [PATCH v3 0/7] User namespace mount updates Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-17 22:00 +0100
                Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 22:40 +0100
                  Re: [PATCH v3 0/7] User namespace mount updates Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-18 13:30 +0100
                    Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-18 15:30 +0100
                      Re: [PATCH v3 0/7] User namespace mount updates Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-18 16:00 +0100
                        Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-18 16:10 +0100
                          Re: [PATCH v3 0/7] User namespace mount updates Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-18 16:20 +0100
                            Re: [PATCH v3 0/7] User namespace mount updates Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-18 16:30 +0100
                              Re: [PATCH v3 0/7] User namespace mount updates James Morris <jmorris@namei.org> - 2015-11-19 08:50 +0100
                                Re: [PATCH v3 0/7] User namespace mount updates Richard Weinberger <richard@nod.at> - 2015-11-19 09:00 +0100
                                  Re: [PATCH v3 0/7] User namespace mount updates "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2015-11-19 15:30 +0100
                                    Re: [PATCH v3 0/7] User namespace mount updates Richard Weinberger <richard@nod.at> - 2015-11-19 16:10 +0100
                                  Re: [PATCH v3 0/7] User namespace mount updates Colin Walters <walters@verbum.org> - 2015-11-19 15:40 +0100
                                    Re: [PATCH v3 0/7] User namespace mount updates Richard Weinberger <richard@nod.at> - 2015-11-19 15:50 +0100
                                      Re: [PATCH v3 0/7] User namespace mount updates "Richard W.M. Jones" <rjones@redhat.com> - 2015-11-19 16:20 +0100
                            Re: [PATCH v3 0/7] User namespace mount updates "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2015-11-19 16:00 +0100
                        Re: [PATCH v3 0/7] User namespace mount updates Nikolay Borisov <kernel@kyup.com> - 2015-11-18 16:40 +0100
                        Re: [PATCH v3 0/7] User namespace mount updates Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-18 16:40 +0100
            Re: [PATCH v3 0/7] User namespace mount updates Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-17 20:40 +0100
              Re: [PATCH v3 0/7] User namespace mount updates Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-17 21:40 +0100
                Re: [PATCH v3 0/7] User namespace mount updates Al Viro <viro@ZenIV.linux.org.uk> - 2015-11-17 22:10 +0100
                  Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-17 23:10 +0100
                    Re: [PATCH v3 0/7] User namespace mount updates Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-18 13:50 +0100
                      Re: [PATCH v3 0/7] User namespace mount updates Seth Forshee <seth.forshee@canonical.com> - 2015-11-18 15:40 +0100
                        Re: [PATCH v3 0/7] User namespace mount updates Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-11-18 16:40 +0100
              Re: [PATCH v3 0/7] User namespace mount updates bfields@fieldses.org (J. Bruce Fields) - 2015-11-18 19:50 +0100

Page 1 of 3  [1] 2 3  Next page →

#1271424 — [PATCH v3 0/7] User namespace mount updates

Hi Eric,

Here's another update to my patches for user namespace mounts, based on
your for-testing branch. These patches add safeguards necessary to allow
unprivileged mounts and update SELinux and Smack to safely handle
device-backed mounts from unprivileged users.

The v2 posting received very little in the way of feedback, so changes
are minimal. I've made a trivial style change to the Smack changes at
Casey's request, and I've added Stephen's ack for the SELinux changes.

Thanks,
Seth

Andy Lutomirski (1):
  fs: Treat foreign mounts as nosuid

Seth Forshee (6):
  block_dev: Support checking inode permissions in lookup_bdev()
  block_dev: Check permissions towards block device inode when mounting
  mtd: Check permissions towards mtd block device inode when mounting
  selinux: Add support for unprivileged mounts from user namespaces
  userns: Replace in_userns with current_in_userns
  Smack: Handle labels consistently in untrusted mounts

 drivers/md/bcache/super.c      |  2 +-
 drivers/md/dm-table.c          |  2 +-
 drivers/mtd/mtdsuper.c         |  6 +++++-
 fs/block_dev.c                 | 18 +++++++++++++++---
 fs/exec.c                      |  2 +-
 fs/namespace.c                 | 13 +++++++++++++
 fs/quota/quota.c               |  2 +-
 include/linux/fs.h             |  2 +-
 include/linux/mount.h          |  1 +
 include/linux/user_namespace.h |  6 ++----
 kernel/user_namespace.c        |  6 +++---
 security/commoncap.c           |  4 ++--
 security/selinux/hooks.c       | 25 ++++++++++++++++++++++++-
 security/smack/smack_lsm.c     | 29 +++++++++++++++++++----------
 14 files changed, 89 insertions(+), 29 deletions(-)

--
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/

[toc] | [next] | [standalone]

#1271425 — [PATCH v3 1/7] block_dev: Support checking inode permissions in lookup_bdev()

When looking up a block device by path no permission check is
done to verify that the user has access to the block device inode
at the specified path. In some cases it may be necessary to
check permissions towards the inode, such as allowing
unprivileged users to mount block devices in user namespaces.

Add an argument to lookup_bdev() to optionally perform this
permission check. A value of 0 skips the permission check and
behaves the same as before. A non-zero value specifies the mask
of access rights required towards the inode at the specified
path. The check is always skipped if the user has CAP_SYS_ADMIN.

All callers of lookup_bdev() currently pass a mask of 0, so this
patch results in no functional change. Subsequent patches will
add permission checks where appropriate.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
 drivers/md/bcache/super.c |  2 +-
 drivers/md/dm-table.c     |  2 +-
 drivers/mtd/mtdsuper.c    |  2 +-
 fs/block_dev.c            | 13 ++++++++++---
 fs/quota/quota.c          |  2 +-
 include/linux/fs.h        |  2 +-
 6 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 679a093a3bf6..e8287b0d1dac 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1926,7 +1926,7 @@ static ssize_t register_bcache(struct kobject *k, struct kobj_attribute *attr,
 				  sb);
 	if (IS_ERR(bdev)) {
 		if (bdev == ERR_PTR(-EBUSY)) {
-			bdev = lookup_bdev(strim(path));
+			bdev = lookup_bdev(strim(path), 0);
 			mutex_lock(&bch_register_lock);
 			if (!IS_ERR(bdev) && bch_is_open(bdev))
 				err = "device already registered";
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index e76ed003769e..35bb3ea4cbe2 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -380,7 +380,7 @@ int dm_get_device(struct dm_target *ti, const char *path, fmode_t mode,
 	BUG_ON(!t);
 
 	/* convert the path to a device */
-	bdev = lookup_bdev(path);
+	bdev = lookup_bdev(path, 0);
 	if (IS_ERR(bdev)) {
 		dev = name_to_dev_t(path);
 		if (!dev)
diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c
index 20c02a3b7417..b5b60e1af31c 100644
--- a/drivers/mtd/mtdsuper.c
+++ b/drivers/mtd/mtdsuper.c
@@ -176,7 +176,7 @@ struct dentry *mount_mtd(struct file_system_type *fs_type, int flags,
 	/* try the old way - the hack where we allowed users to mount
 	 * /dev/mtdblock$(n) but didn't actually _use_ the blockdev
 	 */
-	bdev = lookup_bdev(dev_name);
+	bdev = lookup_bdev(dev_name, 0);
 	if (IS_ERR(bdev)) {
 		ret = PTR_ERR(bdev);
 		pr_debug("MTDSB: lookup_bdev() returned %d\n", ret);
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 26cee058dc02..f1f0aa7214a3 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1396,7 +1396,7 @@ struct block_device *blkdev_get_by_path(const char *path, fmode_t mode,
 	struct block_device *bdev;
 	int err;
 
-	bdev = lookup_bdev(path);
+	bdev = lookup_bdev(path, 0);
 	if (IS_ERR(bdev))
 		return bdev;
 
@@ -1706,12 +1706,14 @@ EXPORT_SYMBOL(ioctl_by_bdev);
 /**
  * lookup_bdev  - lookup a struct block_device by name
  * @pathname:	special file representing the block device
+ * @mask:	rights to check for (%MAY_READ, %MAY_WRITE, %MAY_EXEC)
  *
  * Get a reference to the blockdevice at @pathname in the current
  * namespace if possible and return it.  Return ERR_PTR(error)
- * otherwise.
+ * otherwise.  If @mask is non-zero, check for access rights to the
+ * inode at @pathname.
  */
-struct block_device *lookup_bdev(const char *pathname)
+struct block_device *lookup_bdev(const char *pathname, int mask)
 {
 	struct block_device *bdev;
 	struct inode *inode;
@@ -1726,6 +1728,11 @@ struct block_device *lookup_bdev(const char *pathname)
 		return ERR_PTR(error);
 
 	inode = d_backing_inode(path.dentry);
+	if (mask != 0 && !capable(CAP_SYS_ADMIN)) {
+		error = __inode_permission(inode, mask);
+		if (error)
+			goto fail;
+	}
 	error = -ENOTBLK;
 	if (!S_ISBLK(inode->i_mode))
 		goto fail;
diff --git a/fs/quota/quota.c b/fs/quota/quota.c
index 3746367098fd..a40eaecbd5cc 100644
--- a/fs/quota/quota.c
+++ b/fs/quota/quota.c
@@ -733,7 +733,7 @@ static struct super_block *quotactl_block(const char __user *special, int cmd)
 
 	if (IS_ERR(tmp))
 		return ERR_CAST(tmp);
-	bdev = lookup_bdev(tmp->name);
+	bdev = lookup_bdev(tmp->name, 0);
 	putname(tmp);
 	if (IS_ERR(bdev))
 		return ERR_CAST(bdev);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 458ee7b213be..cc18dfb0b98e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2388,7 +2388,7 @@ static inline void unregister_chrdev(unsigned int major, const char *name)
 #define BLKDEV_MAJOR_HASH_SIZE	255
 extern const char *__bdevname(dev_t, char *buffer);
 extern const char *bdevname(struct block_device *bdev, char *buffer);
-extern struct block_device *lookup_bdev(const char *);
+extern struct block_device *lookup_bdev(const char *, int mask);
 extern void blkdev_show(struct seq_file *,off_t);
 
 #else
-- 
1.9.1

--
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/

[toc] | [prev] | [next] | [standalone]

#1271430 — [PATCH v3 2/7] block_dev: Check permissions towards block device inode when mounting

Unprivileged users should not be able to mount block devices when
they lack sufficient privileges towards the block device inode.
Update blkdev_get_by_path() to validate that the user has the
required access to the inode at the specified path. The check
will be skipped for CAP_SYS_ADMIN, so privileged mounts will
continue working as before.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
 fs/block_dev.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index f1f0aa7214a3..54d94cd64577 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1394,9 +1394,14 @@ struct block_device *blkdev_get_by_path(const char *path, fmode_t mode,
 					void *holder)
 {
 	struct block_device *bdev;
+	int perm = 0;
 	int err;
 
-	bdev = lookup_bdev(path, 0);
+	if (mode & FMODE_READ)
+		perm |= MAY_READ;
+	if (mode & FMODE_WRITE)
+		perm |= MAY_WRITE;
+	bdev = lookup_bdev(path, perm);
 	if (IS_ERR(bdev))
 		return bdev;
 
-- 
1.9.1

--
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/

[toc] | [prev] | [next] | [standalone]

#1271435 — [PATCH v3 3/7] mtd: Check permissions towards mtd block device inode when mounting

Unprivileged users should not be able to mount mtd block devices
when they lack sufficient privileges towards the block device
inode.  Update mount_mtd() to validate that the user has the
required access to the inode at the specified path. The check
will be skipped for CAP_SYS_ADMIN, so privileged mounts will
continue working as before.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
 drivers/mtd/mtdsuper.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c
index b5b60e1af31c..5d7e7705fed8 100644
--- a/drivers/mtd/mtdsuper.c
+++ b/drivers/mtd/mtdsuper.c
@@ -125,6 +125,7 @@ struct dentry *mount_mtd(struct file_system_type *fs_type, int flags,
 #ifdef CONFIG_BLOCK
 	struct block_device *bdev;
 	int ret, major;
+	int perm;
 #endif
 	int mtdnr;
 
@@ -176,7 +177,10 @@ struct dentry *mount_mtd(struct file_system_type *fs_type, int flags,
 	/* try the old way - the hack where we allowed users to mount
 	 * /dev/mtdblock$(n) but didn't actually _use_ the blockdev
 	 */
-	bdev = lookup_bdev(dev_name, 0);
+	perm = MAY_READ;
+	if (!(flags & MS_RDONLY))
+		perm |= MAY_WRITE;
+	bdev = lookup_bdev(dev_name, perm);
 	if (IS_ERR(bdev)) {
 		ret = PTR_ERR(bdev);
 		pr_debug("MTDSB: lookup_bdev() returned %d\n", ret);
-- 
1.9.1

--
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/

[toc] | [prev] | [next] | [standalone]

#1271457

On Tue, Nov 17, 2015 at 10:39:03AM -0600, Seth Forshee wrote:
> Hi Eric,
> 
> Here's another update to my patches for user namespace mounts, based on
> your for-testing branch. These patches add safeguards necessary to allow
> unprivileged mounts and update SELinux and Smack to safely handle
> device-backed mounts from unprivileged users.
> 
> The v2 posting received very little in the way of feedback, so changes
> are minimal. I've made a trivial style change to the Smack changes at
> Casey's request, and I've added Stephen's ack for the SELinux changes.

Would you mind explaining which filesystem types do you plan to allow?
SELinux and the rest of Linux S&M bunch do fuck-all for attacks via
handcrafted fs image fed to the code in fs driver that does not expect
a given kind of inconsistencies.

As it is, validation of on-disk metadata is not particularly strong;
what's more, protection against concurrent malicious *changes* of
fs image (via direct writes by root) is simply inexistent.

So what is that about?
--
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/

[toc] | [prev] | [next] | [standalone]

#1271478

On Tue, Nov 17, 2015 at 05:05:56PM +0000, Al Viro wrote:
> On Tue, Nov 17, 2015 at 10:39:03AM -0600, Seth Forshee wrote:
> > Hi Eric,
> > 
> > Here's another update to my patches for user namespace mounts, based on
> > your for-testing branch. These patches add safeguards necessary to allow
> > unprivileged mounts and update SELinux and Smack to safely handle
> > device-backed mounts from unprivileged users.
> > 
> > The v2 posting received very little in the way of feedback, so changes
> > are minimal. I've made a trivial style change to the Smack changes at
> > Casey's request, and I've added Stephen's ack for the SELinux changes.
> 
> Would you mind explaining which filesystem types do you plan to allow?
> SELinux and the rest of Linux S&M bunch do fuck-all for attacks via
> handcrafted fs image fed to the code in fs driver that does not expect
> a given kind of inconsistencies.
> 
> As it is, validation of on-disk metadata is not particularly strong;
> what's more, protection against concurrent malicious *changes* of
> fs image (via direct writes by root) is simply inexistent.
> 
> So what is that about?

The first target is fuse, which won't be vulnerable to those attacks.

Shortly after that I plan to follow with support for ext4. I've been
fuzzing ext4 for a while now and it has held up well, and I'm currently
working on hand-crafted attacks. Ted has commented privately (to others,
not to me personally) that he will fix bugs for such attacks, though I
haven't seen any public comments to that effect.

Seth
--
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/

[toc] | [prev] | [next] | [standalone]

#1271495

On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> On Tue, Nov 17, 2015 at 05:05:56PM +0000, Al Viro wrote:
> > On Tue, Nov 17, 2015 at 10:39:03AM -0600, Seth Forshee wrote:
> > > Hi Eric,
> > > 
> > > Here's another update to my patches for user namespace mounts, based on
> > > your for-testing branch. These patches add safeguards necessary to allow
> > > unprivileged mounts and update SELinux and Smack to safely handle
> > > device-backed mounts from unprivileged users.
> > > 
> > > The v2 posting received very little in the way of feedback, so changes
> > > are minimal. I've made a trivial style change to the Smack changes at
> > > Casey's request, and I've added Stephen's ack for the SELinux changes.
> > 
> > Would you mind explaining which filesystem types do you plan to allow?
> > SELinux and the rest of Linux S&M bunch do fuck-all for attacks via
> > handcrafted fs image fed to the code in fs driver that does not expect
> > a given kind of inconsistencies.
> > 
> > As it is, validation of on-disk metadata is not particularly strong;
> > what's more, protection against concurrent malicious *changes* of
> > fs image (via direct writes by root) is simply inexistent.
> > 
> > So what is that about?
> 
> The first target is fuse, which won't be vulnerable to those attacks.
> 
> Shortly after that I plan to follow with support for ext4. I've been
> fuzzing ext4 for a while now and it has held up well, and I'm currently
> working on hand-crafted attacks. Ted has commented privately (to others,
> not to me personally) that he will fix bugs for such attacks, though I
> haven't seen any public comments to that effect.

Hi,

Not privately, but during the 2014 kernel summit.  The only documentation
of it I've seen is at the bottom of Paul's summary at
http://lwn.net/Articles/609376/ .
--
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/

[toc] | [prev] | [next] | [standalone]

#1271501

On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:

> Shortly after that I plan to follow with support for ext4. I've been
> fuzzing ext4 for a while now and it has held up well, and I'm currently
> working on hand-crafted attacks. Ted has commented privately (to others,
> not to me personally) that he will fix bugs for such attacks, though I
> haven't seen any public comments to that effect.

_Static_ attacks, or change-image-under-mounted-fs attacks?
--
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/

[toc] | [prev] | [next] | [standalone]

#1271523

On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> 
> > Shortly after that I plan to follow with support for ext4. I've been
> > fuzzing ext4 for a while now and it has held up well, and I'm currently
> > working on hand-crafted attacks. Ted has commented privately (to others,
> > not to me personally) that he will fix bugs for such attacks, though I
> > haven't seen any public comments to that effect.
> 
> _Static_ attacks, or change-image-under-mounted-fs attacks?

Right now only static attacks, change-image-under-mounted-fs attacks
will be next.
--
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/

[toc] | [prev] | [next] | [standalone]

#1271587

On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
<seth.forshee@canonical.com> wrote:
> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>
>> > Shortly after that I plan to follow with support for ext4. I've been
>> > fuzzing ext4 for a while now and it has held up well, and I'm currently
>> > working on hand-crafted attacks. Ted has commented privately (to others,
>> > not to me personally) that he will fix bugs for such attacks, though I
>> > haven't seen any public comments to that effect.
>>
>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>
> Right now only static attacks, change-image-under-mounted-fs attacks
> will be next.

Do we *really* need to enable unprivileged mounting of kernel filesystems?
What about just enabling fuse and implement ext4 and friends as fuse
filesystems?
Using the approaching Linux Kernel Libary[1] this is easy.

[1] https://lkml.org/lkml/2015/11/3/706
-- 
Thanks,
//richard
--
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/

[toc] | [prev] | [next] | [standalone]

#1271592

On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
<seth.forshee@canonical.com> wrote:
>
> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
> > On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
> > <seth.forshee@canonical.com> wrote:
> > > On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> > >> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> > >>
> > >> > Shortly after that I plan to follow with support for ext4. I've been
> > >> > fuzzing ext4 for a while now and it has held up well, and I'm currently
> > >> > working on hand-crafted attacks. Ted has commented privately (to others,
> > >> > not to me personally) that he will fix bugs for such attacks, though I
> > >> > haven't seen any public comments to that effect.
> > >>
> > >> _Static_ attacks, or change-image-under-mounted-fs attacks?
> > >
> > > Right now only static attacks, change-image-under-mounted-fs attacks
> > > will be next.
> >
> > Do we *really* need to enable unprivileged mounting of kernel filesystems?
> > What about just enabling fuse and implement ext4 and friends as fuse
> > filesystems?
> > Using the approaching Linux Kernel Libary[1] this is easy.
>
> I haven't looked at this project, but I'm guessing that programs must be
> written specifically to make use of it? I.e. you can't just use the
> mount syscall, and thus all existing software still doesn't work?
>

The projects includes a lklfuse program that uses fuse to mount a
fileystem image.
--
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/

[toc] | [prev] | [next] | [standalone]

#1271632

Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
> <seth.forshee@canonical.com> wrote:
>>
>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>>> <seth.forshee@canonical.com> wrote:
>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>>>
>>>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>>>> haven't seen any public comments to that effect.
>>>>>
>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>>>>
>>>> Right now only static attacks, change-image-under-mounted-fs attacks
>>>> will be next.
>>>
>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>>> What about just enabling fuse and implement ext4 and friends as fuse
>>> filesystems?
>>> Using the approaching Linux Kernel Libary[1] this is easy.
>>
>> I haven't looked at this project, but I'm guessing that programs must be
>> written specifically to make use of it? I.e. you can't just use the
>> mount syscall, and thus all existing software still doesn't work?
>>
> 
> The projects includes a lklfuse program that uses fuse to mount a
> fileystem image.

Cool. I gave it a try.
It seems to work fine, but only if I run it in foreground (using -d)
otherwise fuse blocks every filesystem request.

Thanks,
//richard
--
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/

[toc] | [prev] | [next] | [standalone]

#1271693

On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
>> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
>> <seth.forshee@canonical.com> wrote:
>>>
>>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>>>> <seth.forshee@canonical.com> wrote:
>>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>>>>
>>>>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>>>>> haven't seen any public comments to that effect.
>>>>>>
>>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>>>>>
>>>>> Right now only static attacks, change-image-under-mounted-fs attacks
>>>>> will be next.
>>>>
>>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>>>> What about just enabling fuse and implement ext4 and friends as fuse
>>>> filesystems?
>>>> Using the approaching Linux Kernel Libary[1] this is easy.
>>>
>>> I haven't looked at this project, but I'm guessing that programs must be
>>> written specifically to make use of it? I.e. you can't just use the
>>> mount syscall, and thus all existing software still doesn't work?
>>>
>>
>> The projects includes a lklfuse program that uses fuse to mount a
>> fileystem image.
>
> Cool. I gave it a try.
> It seems to work fine, but only if I run it in foreground (using -d)
> otherwise fuse blocks every filesystem request.
>

Now it should work in the background as well, thanks for reporting the issue.
--
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/

[toc] | [prev] | [next] | [standalone]

#1273215

On Wed, Nov 18, 2015 at 12:00:17AM +0200, Octavian Purdila wrote:
> On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger <richard@nod.at> wrote:
> > Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
> >> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
> >> <seth.forshee@canonical.com> wrote:
> >>>
> >>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
> >>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
> >>>> <seth.forshee@canonical.com> wrote:
> >>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> >>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> >>>>>>
> >>>>>>> Shortly after that I plan to follow with support for ext4. I've been
> >>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
> >>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
> >>>>>>> not to me personally) that he will fix bugs for such attacks, though I
> >>>>>>> haven't seen any public comments to that effect.
> >>>>>>
> >>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
> >>>>>
> >>>>> Right now only static attacks, change-image-under-mounted-fs attacks
> >>>>> will be next.
> >>>>
> >>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
> >>>> What about just enabling fuse and implement ext4 and friends as fuse
> >>>> filesystems?
> >>>> Using the approaching Linux Kernel Libary[1] this is easy.
> >>>
> >>> I haven't looked at this project, but I'm guessing that programs must be
> >>> written specifically to make use of it? I.e. you can't just use the
> >>> mount syscall, and thus all existing software still doesn't work?
> >>>
> >>
> >> The projects includes a lklfuse program that uses fuse to mount a
> >> fileystem image.
> >
> > Cool. I gave it a try.
> > It seems to work fine, but only if I run it in foreground (using -d)
> > otherwise fuse blocks every filesystem request.
> >
> 
> Now it should work in the background as well, thanks for reporting the issue.

I'm playing with lklfuse now, it's surprisingly easy to get up and
running. I did have a few problems though that I thought you'd like to
know about.

Unfortunately I still can't run it in background mode, I get a segfault.

It's working fine on light workloads, but I'm having issues when I start
trying to stress it. In a couple runs of the stress-ng filesystem
stressors I saw both stress-ng and lklfuse get stuck in uninterruptible
sleep during the first run, and during the second I got some OOM errors
in lklfuse followed by I/O errors and eventually a journal error that
cause the filesystem to go read-only.

The command I used for the first run was:

 stress-ng --class filesystem --all 0

And for the second:

 stress-ng --class filesystem --seq 0 -v -t 60

There really wasn't anything interesting in the lklfuse output for the
first run, but for the second run I pasted the output here:
http://paste.ubuntu.com/13346993/

I still need to compare this to other fuse filesystems since I haven't
tried this kind of stress test on any others.
--
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/

[toc] | [prev] | [next] | [standalone]

#1273261

On Thu, Nov 19, 2015 at 5:23 PM, Seth Forshee
<seth.forshee@canonical.com> wrote:
> On Wed, Nov 18, 2015 at 12:00:17AM +0200, Octavian Purdila wrote:
>> On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger <richard@nod.at> wrote:
>> > Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
>> >> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
>> >> <seth.forshee@canonical.com> wrote:
>> >>>
>> >>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>> >>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>> >>>> <seth.forshee@canonical.com> wrote:
>> >>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>> >>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>> >>>>>>
>> >>>>>>> Shortly after that I plan to follow with support for ext4. I've been
>> >>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>> >>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>> >>>>>>> not to me personally) that he will fix bugs for such attacks, though I
>> >>>>>>> haven't seen any public comments to that effect.
>> >>>>>>
>> >>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>> >>>>>
>> >>>>> Right now only static attacks, change-image-under-mounted-fs attacks
>> >>>>> will be next.
>> >>>>
>> >>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>> >>>> What about just enabling fuse and implement ext4 and friends as fuse
>> >>>> filesystems?
>> >>>> Using the approaching Linux Kernel Libary[1] this is easy.
>> >>>
>> >>> I haven't looked at this project, but I'm guessing that programs must be
>> >>> written specifically to make use of it? I.e. you can't just use the
>> >>> mount syscall, and thus all existing software still doesn't work?
>> >>>
>> >>
>> >> The projects includes a lklfuse program that uses fuse to mount a
>> >> fileystem image.
>> >
>> > Cool. I gave it a try.
>> > It seems to work fine, but only if I run it in foreground (using -d)
>> > otherwise fuse blocks every filesystem request.
>> >
>>
>> Now it should work in the background as well, thanks for reporting the issue.
>

Hi Seth,

> I'm playing with lklfuse now, it's surprisingly easy to get up and
> running. I did have a few problems though that I thought you'd like to
> know about.
>

Great, thanks for giving it a try and reporting the issues.

> Unfortunately I still can't run it in background mode, I get a segfault.

I got it to reproduce as well now. Not sure why how it worked before,
probably a race condition between lkl initialization and fuse calls.

> It's working fine on light workloads, but I'm having issues when I start
> trying to stress it. In a couple runs of the stress-ng filesystem
> stressors I saw both stress-ng and lklfuse get stuck in uninterruptible
> sleep during the first run, and during the second I got some OOM errors
> in lklfuse followed by I/O errors and eventually a journal error that
> cause the filesystem to go read-only.
>
> The command I used for the first run was:
>
>  stress-ng --class filesystem --all 0
>

I will reproduce it and take a look.

> And for the second:
>
>  stress-ng --class filesystem --seq 0 -v -t 60
>
> There really wasn't anything interesting in the lklfuse output for the
> first run, but for the second run I pasted the output here:
> http://paste.ubuntu.com/13346993/

lklfuse allocates a fixed 100MB to the kernel and this is probably not
enough. For the short term I can add a parameter to lklfuse that
allows the user to specify the amount of memory to allocate to lkl. A
better fix would probably be to dynamically adjust the memory size of
lkl. I am thinking of using the ballon virtio driver or the memory
hotplug infrastructure. Any other suggestions?

I created a couple of issues in github [1] that you can track if you
want - I want to avoid spamming the list with reporting progress on
them.

[1] https://github.com/lkl/linux/issues
--
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/

[toc] | [prev] | [next] | [standalone]

#1273281

On Thu, Nov 19, 2015 at 06:19:10PM +0200, Octavian Purdila wrote:
> On Thu, Nov 19, 2015 at 5:23 PM, Seth Forshee
> <seth.forshee@canonical.com> wrote:
> > On Wed, Nov 18, 2015 at 12:00:17AM +0200, Octavian Purdila wrote:
> >> On Tue, Nov 17, 2015 at 10:12 PM, Richard Weinberger <richard@nod.at> wrote:
> >> > Am 17.11.2015 um 20:25 schrieb Octavian Purdila:
> >> >> On Tue, Nov 17, 2015 at 9:21 PM, Seth Forshee
> >> >> <seth.forshee@canonical.com> wrote:
> >> >>>
> >> >>> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
> >> >>>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
> >> >>>> <seth.forshee@canonical.com> wrote:
> >> >>>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> >> >>>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> >> >>>>>>
> >> >>>>>>> Shortly after that I plan to follow with support for ext4. I've been
> >> >>>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
> >> >>>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
> >> >>>>>>> not to me personally) that he will fix bugs for such attacks, though I
> >> >>>>>>> haven't seen any public comments to that effect.
> >> >>>>>>
> >> >>>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
> >> >>>>>
> >> >>>>> Right now only static attacks, change-image-under-mounted-fs attacks
> >> >>>>> will be next.
> >> >>>>
> >> >>>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
> >> >>>> What about just enabling fuse and implement ext4 and friends as fuse
> >> >>>> filesystems?
> >> >>>> Using the approaching Linux Kernel Libary[1] this is easy.
> >> >>>
> >> >>> I haven't looked at this project, but I'm guessing that programs must be
> >> >>> written specifically to make use of it? I.e. you can't just use the
> >> >>> mount syscall, and thus all existing software still doesn't work?
> >> >>>
> >> >>
> >> >> The projects includes a lklfuse program that uses fuse to mount a
> >> >> fileystem image.
> >> >
> >> > Cool. I gave it a try.
> >> > It seems to work fine, but only if I run it in foreground (using -d)
> >> > otherwise fuse blocks every filesystem request.
> >> >
> >>
> >> Now it should work in the background as well, thanks for reporting the issue.
> >
> 
> Hi Seth,
> 
> > I'm playing with lklfuse now, it's surprisingly easy to get up and
> > running. I did have a few problems though that I thought you'd like to
> > know about.
> >
> 
> Great, thanks for giving it a try and reporting the issues.

No problem, looks like a promising project.

> > Unfortunately I still can't run it in background mode, I get a segfault.
> 
> I got it to reproduce as well now. Not sure why how it worked before,
> probably a race condition between lkl initialization and fuse calls.
> 
> > It's working fine on light workloads, but I'm having issues when I start
> > trying to stress it. In a couple runs of the stress-ng filesystem
> > stressors I saw both stress-ng and lklfuse get stuck in uninterruptible
> > sleep during the first run, and during the second I got some OOM errors
> > in lklfuse followed by I/O errors and eventually a journal error that
> > cause the filesystem to go read-only.
> >
> > The command I used for the first run was:
> >
> >  stress-ng --class filesystem --all 0
> >
> 
> I will reproduce it and take a look.
> 
> > And for the second:
> >
> >  stress-ng --class filesystem --seq 0 -v -t 60
> >
> > There really wasn't anything interesting in the lklfuse output for the
> > first run, but for the second run I pasted the output here:
> > http://paste.ubuntu.com/13346993/
> 
> lklfuse allocates a fixed 100MB to the kernel and this is probably not
> enough. For the short term I can add a parameter to lklfuse that
> allows the user to specify the amount of memory to allocate to lkl. A
> better fix would probably be to dynamically adjust the memory size of
> lkl. I am thinking of using the ballon virtio driver or the memory
> hotplug infrastructure. Any other suggestions?
> 
> I created a couple of issues in github [1] that you can track if you
> want - I want to avoid spamming the list with reporting progress on
> them.

Makes sense, I'm watching those issues now and will direct any furure
discussion there. Thanks!
--
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/

[toc] | [prev] | [next] | [standalone]

#1274312

On Thu, Nov 19, 2015 at 06:19:10PM +0200, Octavian Purdila wrote:
> On Thu, Nov 19, 2015 at 5:23 PM, Seth Forshee
> > And for the second:
> >
> >  stress-ng --class filesystem --seq 0 -v -t 60
> >
> > There really wasn't anything interesting in the lklfuse output for the
> > first run, but for the second run I pasted the output here:
> > http://paste.ubuntu.com/13346993/
> 
> lklfuse allocates a fixed 100MB to the kernel and this is probably not
> enough. For the short term I can add a parameter to lklfuse that
> allows the user to specify the amount of memory to allocate to lkl. A
> better fix would probably be to dynamically adjust the memory size of
> lkl. I am thinking of using the ballon virtio driver or the memory
> hotplug infrastructure. Any other suggestions?

Hi Octavian,

Like Seth said this was very nice to install and run.  But I think I'm
doing something wrong.  I cloned the lkl/linux git tree into a 9G ext4
loopback file, both one mounted with lkl and one mounted as loopback.
The results were worse than I expected - loopback was 0m10.078s for
clone and 0m0.877s for rm -rf;  lkl was 5m5.625s for clone and 0m44.332s
for rm -rf.  I assume this has to do with the 100MB buffer and subsequent
thrashing?  How should I tune this to  make it perform better?

No crashes from this, though.

thanks,
-serge
--
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/

[toc] | [prev] | [next] | [standalone]

#1271597

Am 17.11.2015 um 20:21 schrieb Seth Forshee:
> On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
>> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
>> <seth.forshee@canonical.com> wrote:
>>> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
>>>> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>>>>
>>>>> Shortly after that I plan to follow with support for ext4. I've been
>>>>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>>>>> working on hand-crafted attacks. Ted has commented privately (to others,
>>>>> not to me personally) that he will fix bugs for such attacks, though I
>>>>> haven't seen any public comments to that effect.
>>>>
>>>> _Static_ attacks, or change-image-under-mounted-fs attacks?
>>>
>>> Right now only static attacks, change-image-under-mounted-fs attacks
>>> will be next.
>>
>> Do we *really* need to enable unprivileged mounting of kernel filesystems?
>> What about just enabling fuse and implement ext4 and friends as fuse
>> filesystems?
>> Using the approaching Linux Kernel Libary[1] this is easy.
> 
> I haven't looked at this project, but I'm guessing that programs must be
> written specifically to make use of it? I.e. you can't just use the
> mount syscall, and thus all existing software still doesn't work?

You can easy bridge fuse and the LKL, I did already a hacky PoC. Worked nicely.
Octavian's tree has some nice examples, and AFAIK he is currently working
on a "mount any kernel fs via fuse" tool.

Thanks,
//richard
--
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/

[toc] | [prev] | [next] | [standalone]

#1271600

On Tue, Nov 17, 2015 at 08:12:31PM +0100, Richard Weinberger wrote:
> On Tue, Nov 17, 2015 at 7:34 PM, Seth Forshee
> <seth.forshee@canonical.com> wrote:
> > On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> >> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> >>
> >> > Shortly after that I plan to follow with support for ext4. I've been
> >> > fuzzing ext4 for a while now and it has held up well, and I'm currently
> >> > working on hand-crafted attacks. Ted has commented privately (to others,
> >> > not to me personally) that he will fix bugs for such attacks, though I
> >> > haven't seen any public comments to that effect.
> >>
> >> _Static_ attacks, or change-image-under-mounted-fs attacks?
> >
> > Right now only static attacks, change-image-under-mounted-fs attacks
> > will be next.
> 
> Do we *really* need to enable unprivileged mounting of kernel filesystems?
> What about just enabling fuse and implement ext4 and friends as fuse
> filesystems?
> Using the approaching Linux Kernel Libary[1] this is easy.

I haven't looked at this project, but I'm guessing that programs must be
written specifically to make use of it? I.e. you can't just use the
mount syscall, and thus all existing software still doesn't work?

> [1] https://lkml.org/lkml/2015/11/3/706
> -- 
> Thanks,
> //richard
--
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/

[toc] | [prev] | [next] | [standalone]

#1272492

On Tue, Nov 17, 2015 at 12:34:44PM -0600, Seth Forshee wrote:
> On Tue, Nov 17, 2015 at 05:55:06PM +0000, Al Viro wrote:
> > On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
> > 
> > > Shortly after that I plan to follow with support for ext4. I've been
> > > fuzzing ext4 for a while now and it has held up well, and I'm currently
> > > working on hand-crafted attacks. Ted has commented privately (to others,
> > > not to me personally) that he will fix bugs for such attacks, though I
> > > haven't seen any public comments to that effect.
> > 
> > _Static_ attacks, or change-image-under-mounted-fs attacks?
> 
> Right now only static attacks, change-image-under-mounted-fs attacks
> will be next.

I will fix bugs about static attacks.  That is, it's interesting to me
that a buggy file system (no matter how it is created), not cause the
kernel to crash --- and privilege escalation attacks tend to be
strongly related to those bugs where we're not doing strong enough
checking.

Protecting against a malicious user which changes the image under the
file system is a whole other kettle of fish.  I am not at all user you
can do this without completely sacrificing performance or making the
code impossible to maintain.  So my comments do *not* extend to
protecting against a malicious user who is changing the block device
underneath the kernel.

If you want to submit patches to make the kernel more robust against
these attacks, I'm certainly willing to look at the patches.  But I'm
certainly not guaranteeing that they will go in, and I'm certainly not
promising to fix all vulnerabilities that you might find that are
caused by a malicious block device.  Sorry, that's too much buying a
pig in a poke....

						- Ted
				
--
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/

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel

csiph-web