From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Daniel Walsh <dwalsh@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Casey Schaufler <casey@schaufler-ca.com>,
"Schaufler, Casey" <casey.schaufler@intel.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"virtio-fs@redhat.com" <virtio-fs@redhat.com>,
"berrange@redhat.com" <berrange@redhat.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>
Subject: Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE
Date: Thu, 1 Jul 2021 09:48:33 +0100 [thread overview]
Message-ID: <YN2BYXv79PswrN2E@work-vm> (raw)
In-Reply-To: <YNzNLTxflKbDi8W2@mit.edu>
* Theodore Ts'o (tytso@mit.edu) wrote:
> On Wed, Jun 30, 2021 at 04:01:42PM +0100, Dr. David Alan Gilbert wrote:
> >
> > Even if you fix symlinks, I don't think it fixes device nodes or
> > anything else where the permissions bitmap isn't purely used as the
> > permissions on the inode.
>
> I think we're making a mountain out of a molehill. Again, very few
> people are using quota these days. And if you give someone write
> access to a 8TB disk, do you really care if they can "steal" 32k worth
> of space (which is the maximum size of an xattr, enforced by the VFS).
>
> OK, but what about character mode devices? First of all, most users
> don't have access to huge number of devices, but let's assume
> something absurd. Let's say that a user has write access to *1024*
> devices. (My /dev has 233 character mode devices, and I have write
> access to well under a dozen.)
>
> An 8TB disk costs about $200. So how much of the "stolen" quota space
> are we talking about, assuming the user has access to 1024 devices,
> and the file system actually supports a 32k xattr.
>
> 32k * 1024 * $200 / 8TB / (1024*1024*1024) = $0.000763 = 0.0763 cents
>
> A 2TB SSD is less around $180, so even if we calculate the prices
> based on SSD space, we're still talking about a quarter of a penny.
>
> Why are we worrying about this?
I'm not worrying about storage cost, but we would need to define what
the rules are on who can write and change a user.* xattr on a device
node. It doesn't feel sane to make it anyone who can write to the
device; then everyone can start leaving droppings on /dev/null.
The other evilness I can imagine, is if there's a 32k limit on xattrs on
a node, an evil user could write almost 32k of junk to the node
and then break the next login that tries to add an acl or breaks the
next relabel.
Dave
> - Ted
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: "berrange@redhat.com" <berrange@redhat.com>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"virtio-fs@redhat.com" <virtio-fs@redhat.com>,
"Schaufler, Casey" <casey.schaufler@intel.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
Casey Schaufler <casey@schaufler-ca.com>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [Virtio-fs] [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE
Date: Thu, 1 Jul 2021 09:48:33 +0100 [thread overview]
Message-ID: <YN2BYXv79PswrN2E@work-vm> (raw)
In-Reply-To: <YNzNLTxflKbDi8W2@mit.edu>
* Theodore Ts'o (tytso@mit.edu) wrote:
> On Wed, Jun 30, 2021 at 04:01:42PM +0100, Dr. David Alan Gilbert wrote:
> >
> > Even if you fix symlinks, I don't think it fixes device nodes or
> > anything else where the permissions bitmap isn't purely used as the
> > permissions on the inode.
>
> I think we're making a mountain out of a molehill. Again, very few
> people are using quota these days. And if you give someone write
> access to a 8TB disk, do you really care if they can "steal" 32k worth
> of space (which is the maximum size of an xattr, enforced by the VFS).
>
> OK, but what about character mode devices? First of all, most users
> don't have access to huge number of devices, but let's assume
> something absurd. Let's say that a user has write access to *1024*
> devices. (My /dev has 233 character mode devices, and I have write
> access to well under a dozen.)
>
> An 8TB disk costs about $200. So how much of the "stolen" quota space
> are we talking about, assuming the user has access to 1024 devices,
> and the file system actually supports a 32k xattr.
>
> 32k * 1024 * $200 / 8TB / (1024*1024*1024) = $0.000763 = 0.0763 cents
>
> A 2TB SSD is less around $180, so even if we calculate the prices
> based on SSD space, we're still talking about a quarter of a penny.
>
> Why are we worrying about this?
I'm not worrying about storage cost, but we would need to define what
the rules are on who can write and change a user.* xattr on a device
node. It doesn't feel sane to make it anyone who can write to the
device; then everyone can start leaving droppings on /dev/null.
The other evilness I can imagine, is if there's a 32k limit on xattrs on
a node, an evil user could write almost 32k of junk to the node
and then break the next login that tries to add an acl or breaks the
next relabel.
Dave
> - Ted
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2021-07-01 8:48 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 19:12 [Virtio-fs] [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Vivek Goyal
2021-06-25 19:12 ` Vivek Goyal
2021-06-25 19:12 ` [Virtio-fs] [PATCH 1/1] xattr: Allow user.* xattr on symlink/special files with CAP_SYS_RESOURCE Vivek Goyal
2021-06-25 19:12 ` Vivek Goyal
2021-06-28 12:33 ` [Virtio-fs] " Christian Brauner
2021-06-28 12:33 ` Christian Brauner
2021-06-28 15:00 ` [Virtio-fs] " Vivek Goyal
2021-06-28 15:00 ` Vivek Goyal
2021-06-29 3:13 ` [LTP] [xattr] 8d8cd767b6: ltp.setxattr02.fail kernel test robot
2021-06-29 3:13 ` kernel test robot
2021-06-29 3:13 ` [Virtio-fs] " kernel test robot
2021-06-29 3:13 ` kernel test robot
2021-06-29 12:59 ` [LTP] " Vivek Goyal
2021-06-29 12:59 ` Vivek Goyal
2021-06-29 12:59 ` [Virtio-fs] " Vivek Goyal
2021-06-29 12:59 ` Vivek Goyal
2021-06-25 21:49 ` [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Schaufler, Casey
2021-06-25 21:49 ` [Virtio-fs] " Schaufler, Casey
2021-06-28 11:58 ` Dr. David Alan Gilbert
2021-06-28 11:58 ` [Virtio-fs] " Dr. David Alan Gilbert
2021-06-28 13:17 ` Vivek Goyal
2021-06-28 13:17 ` [Virtio-fs] " Vivek Goyal
2021-06-28 13:36 ` Daniel Walsh
2021-06-28 13:36 ` [Virtio-fs] " Daniel Walsh
2021-06-28 16:04 ` Casey Schaufler
2021-06-28 16:04 ` [Virtio-fs] " Casey Schaufler
2021-06-28 16:28 ` Dr. David Alan Gilbert
2021-06-28 16:28 ` [Virtio-fs] " Dr. David Alan Gilbert
2021-06-28 17:41 ` Casey Schaufler
2021-06-28 17:41 ` [Virtio-fs] " Casey Schaufler
2021-06-29 9:00 ` Dr. David Alan Gilbert
2021-06-29 9:00 ` [Virtio-fs] " Dr. David Alan Gilbert
2021-06-29 14:38 ` Casey Schaufler
2021-06-29 14:38 ` [Virtio-fs] " Casey Schaufler
2021-06-29 15:20 ` Vivek Goyal
2021-06-29 15:20 ` [Virtio-fs] " Vivek Goyal
2021-06-29 16:13 ` Casey Schaufler
2021-06-29 16:13 ` [Virtio-fs] " Casey Schaufler
2021-06-29 16:35 ` Dr. David Alan Gilbert
2021-06-29 16:35 ` [Virtio-fs] " Dr. David Alan Gilbert
2021-06-29 16:51 ` Casey Schaufler
2021-06-29 16:51 ` [Virtio-fs] " Casey Schaufler
2021-06-29 17:35 ` Vivek Goyal
2021-06-29 17:35 ` [Virtio-fs] " Vivek Goyal
2021-06-29 20:28 ` Daniel Walsh
2021-06-29 20:28 ` [Virtio-fs] " Daniel Walsh
2021-06-30 4:12 ` Theodore Ts'o
2021-06-30 4:12 ` [Virtio-fs] " Theodore Ts'o
2021-06-30 8:07 ` Dr. David Alan Gilbert
2021-06-30 8:07 ` [Virtio-fs] " Dr. David Alan Gilbert
2021-06-30 14:47 ` Theodore Ts'o
2021-06-30 14:47 ` [Virtio-fs] " Theodore Ts'o
2021-06-30 15:01 ` Dr. David Alan Gilbert
2021-06-30 15:01 ` [Virtio-fs] " Dr. David Alan Gilbert
2021-06-30 19:59 ` Theodore Ts'o
2021-06-30 19:59 ` [Virtio-fs] " Theodore Ts'o
2021-06-30 20:32 ` Vivek Goyal
2021-06-30 20:32 ` [Virtio-fs] " Vivek Goyal
2021-07-01 8:48 ` Dr. David Alan Gilbert [this message]
2021-07-01 8:48 ` Dr. David Alan Gilbert
2021-07-01 12:21 ` Vivek Goyal
2021-07-01 12:21 ` [Virtio-fs] " Vivek Goyal
2021-07-01 13:10 ` Vivek Goyal
2021-07-01 13:10 ` [Virtio-fs] " Vivek Goyal
2021-07-01 16:58 ` Casey Schaufler
2021-07-01 16:58 ` [Virtio-fs] " Casey Schaufler
2021-06-30 16:09 ` Vivek Goyal
2021-06-30 16:09 ` [Virtio-fs] " Vivek Goyal
2021-06-30 14:27 ` Vivek Goyal
2021-06-30 14:27 ` [Virtio-fs] " Vivek Goyal
2021-06-29 16:25 ` Theodore Ts'o
2021-06-29 16:25 ` [Virtio-fs] " Theodore Ts'o
2021-06-28 17:22 ` Vivek Goyal
2021-06-28 17:22 ` [Virtio-fs] " Vivek Goyal
2021-06-28 18:55 ` Daniel Walsh
2021-06-28 18:55 ` [Virtio-fs] " Daniel Walsh
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=YN2BYXv79PswrN2E@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=casey.schaufler@intel.com \
--cc=casey@schaufler-ca.com \
--cc=dwalsh@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=selinux@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=vgoyal@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=virtio-fs@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.