Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1271424 > unrolled thread
| Started by | Seth Forshee <seth.forshee@canonical.com> |
|---|---|
| First post | 2015-11-17 17:50 +0100 |
| Last post | 2015-11-18 19:50 +0100 |
| Articles | 10 on this page of 50 — 15 participants |
Back to article view | Back to linux.kernel
[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 3 of 3 — ← Prev page 1 2 [3]
| From | Nikolay Borisov <kernel@kyup.com> |
|---|---|
| Date | 2015-11-18 16:40 +0100 |
| Message-ID | <qwcZY-4Lu-21@gated-at.bofh.it> |
| In reply to | #1272262 |
On 11/18/2015 04:58 PM, Al Viro wrote: > On Wed, Nov 18, 2015 at 08:22:38AM -0600, Seth Forshee wrote: > >> But it still requires the admin set it up that way, no? And aren't >> privileges required to set up those devices in the first place? >> >> I'm not saying that it wouldn't be a good idea to lock down the backing >> stores for those types of devices too, just that it isn't something that >> a regular user could exploit without an admin doing something to >> facilitate it. > > Sigh... If it boils down to "all admins within all containers must be > trusted not to try and break out" (along with "roothole in any container > escalates to kernel-mode code execution on host"), then what the fuck > is the *point* of bothering with containers, userns, etc. in the first > place? If your model is basically "you want isolation, just use kvm", > fine, but where's the place for userns in all that? > > And if you are talking about the _host_ admin, then WTF not have him just > mount what's needed as part of setup and to hell with mounting those > inside the container? > > Look at that from the hosting company POV - they are offering a bunch of > virtual machines on one physical system. And you want the admins on those > virtual machines independent from the host admin. Fine, but then you > really need to keep them unable to screw each other or gain kernel-mode > execution on the host. Actually from the POV of a hosting company there's also the use case of wanting to use container as substitutes for virtual machines (of course we are a long way from that). But being able to do what those patches enable (i.e. what Seth has pointed to with mount -o loop) is beneficial and desirable. > > Again, what's the point of all that? I assumed the model where containers > do, you know, contain what's in them, regardless of trust. You guys seem > to assume something different and I really wonder what it _is_... > -- > 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/ > -- 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]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-11-18 16:40 +0100 |
| Message-ID | <qwcZZ-4Lu-29@gated-at.bofh.it> |
| In reply to | #1272262 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-11-18 09:58, Al Viro wrote: > On Wed, Nov 18, 2015 at 08:22:38AM -0600, Seth Forshee wrote: > >> But it still requires the admin set it up that way, no? And aren't >> privileges required to set up those devices in the first place? >> >> I'm not saying that it wouldn't be a good idea to lock down the backing >> stores for those types of devices too, just that it isn't something that >> a regular user could exploit without an admin doing something to >> facilitate it. > > Sigh... If it boils down to "all admins within all containers must be > trusted not to try and break out" (along with "roothole in any container > escalates to kernel-mode code execution on host"), then what the fuck > is the *point* of bothering with containers, userns, etc. in the first > place? If your model is basically "you want isolation, just use kvm", > fine, but where's the place for userns in all that? In this case, Seth is referring to the host admin, not the container admin. > > And if you are talking about the _host_ admin, then WTF not have him just > mount what's needed as part of setup and to hell with mounting those > inside the container? This is decidedly non-trivial to handle in some cases. IIRC, one of the particular things that sparked this in the first place was the Chrome Native Client having to have CAP_SYS_ADMIN or SUID set on it to handle setting up it's own sandbox, which is not something that should ever be set on an executable that runs untrusted code (which is the whole point of NaCl). > > Look at that from the hosting company POV - they are offering a bunch of > virtual machines on one physical system. And you want the admins on those > virtual machines independent from the host admin. Fine, but then you > really need to keep them unable to screw each other or gain kernel-mode > execution on the host. > > Again, what's the point of all that? I assumed the model where containers > do, you know, contain what's in them, regardless of trust. You guys seem > to assume something different and I really wonder what it _is_... Yes, hosting and isolation of untrusted code are valid uses for containers, which is why I suggested the ability to disallow mounts other than FUSE, and make that the default state. There are other perfectly valid uses for them as well, and for me the two I'm particularly interested in are safe deployment of a new system from an existing system (ala Gentoo or Arch installation, or manual installation of *BSD), and running non-native distros without virtualization (On a single user system, virtualization is overkill when all you want is a Debian or Fedora or Arch testing environment and don't care about their specific kernel features).
[toc] | [prev] | [next] | [standalone]
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Date | 2015-11-17 20:40 +0100 |
| Message-ID | <qvUgG-Qn-11@gated-at.bofh.it> |
| In reply to | #1271577 |
On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote: > >_Static_ attacks, or change-image-under-mounted-fs attacks? > To properly protect against attacks on mounted filesystems, we'd > need some new concept of a userspace immutable file (that is, one > where nobody can write to it except the kernel, and only the kernel > can change it between regular access and this new state), and then > have the kernel set an image (or block device) to this state when a > filesystem is mounted from it (this introduces all kinds of other > issues too however, for example stuff that allows an online fsck on > the device will stop working, as will many un-deletion tools). > > The only other option would be to force the FS to cache all metadata > in memory, and validate between the cache and what's on disk on > every access, which is not realistic for any real world system. Doctor, it hurt when I do it... IOW, the other option is to refuse attempting this insanity. Fuse probably can be handled, but being able to mount (with kernel-space drivera) an arbitrary ext4 image is equivalent to being able to do anything and it's going to stay that way for the forseeable future. You are talking about a large pile of code that deals with rather convoluted data structure, had not been written with validation in mind *and* keeps being developed. What's more, that code runs with maximal priveleges there are. This is absolutely insane, no matter how much LSM snake oil you slatter on the whole thing. All of a sudden you are exposing a huge attack surface in the place where it would hurt most and as the consolation we are offered basically "Ted is willing to fix holes when they are found". I know that security community tends to be less than sane, but this really takes the damn cake. Al, still not quite able to believe this is not a badly mistimed AFD posting... -- 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]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-11-17 21:40 +0100 |
| Message-ID | <qvVcK-1sl-29@gated-at.bofh.it> |
| In reply to | #1271604 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-11-17 14:30, Al Viro wrote: > On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote: > >>> _Static_ attacks, or change-image-under-mounted-fs attacks? >> To properly protect against attacks on mounted filesystems, we'd >> need some new concept of a userspace immutable file (that is, one >> where nobody can write to it except the kernel, and only the kernel >> can change it between regular access and this new state), and then >> have the kernel set an image (or block device) to this state when a >> filesystem is mounted from it (this introduces all kinds of other >> issues too however, for example stuff that allows an online fsck on >> the device will stop working, as will many un-deletion tools). >> >> The only other option would be to force the FS to cache all metadata >> in memory, and validate between the cache and what's on disk on >> every access, which is not realistic for any real world system. > > Doctor, it hurt when I do it... > > IOW, the other option is to refuse attempting this insanity. Fuse probably > can be handled, but being able to mount (with kernel-space drivera) an > arbitrary ext4 image is equivalent to being able to do anything and it's > going to stay that way for the forseeable future. You are talking about > a large pile of code that deals with rather convoluted data structure, > had not been written with validation in mind *and* keeps being developed. > What's more, that code runs with maximal priveleges there are. Without factoring in unprivileged mounts, for cases when mounting from a block device, you shouldn't have to worry about a malicious third party, because their ability to modify it under the filesystem implies that they either already have root privileges, or they have direct access to hardware, and in both cases, your system is already compromised to a degree that makes the reliability of your filesystem irrelevant. Under the same circumstances with filesystem images, the same statement applies. However, while unprivileged mounts make validation more important, there is still the fact that if you don't trust someone, then you shouldn't be letting them have access to your system. No amount of sandboxing short of full isolation can solve that, period. Yes people will try to crack the system, but no matter how much sandboxing there is, it will not be unbreakable unless nobody can access it. The attack surface is already there, it's just hard to get to. There's a reason I never mount anything I didn't create myself and can't prove chain of custody on without at least running fsck on it first, and then only mount it with the kernel if there isn't a FUSE driver for it that I trust (and GRUB provides a lot of those). > > This is absolutely insane, no matter how much LSM snake oil you slatter on > the whole thing. All of a sudden you are exposing a huge attack surface > in the place where it would hurt most and as the consolation we are offered > basically "Ted is willing to fix holes when they are found". For the context of static image attacks, anything that's found _needs_ to be fixed regardless, and unless you can find some way to actually prevent attacks on mounted filesystems that doesn't involve a complete re-write of the filesystem drivers, then there's not much we can do about it. Yes, unprivileged mounts expose an attack surface, but so does userspace access to the network stack, and so do a lot of other features that are considered essential in a modern general purpose operating system.
[toc] | [prev] | [next] | [standalone]
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Date | 2015-11-17 22:10 +0100 |
| Message-ID | <qvVFM-1Tz-9@gated-at.bofh.it> |
| In reply to | #1271640 |
On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote: > >This is absolutely insane, no matter how much LSM snake oil you slatter on > >the whole thing. All of a sudden you are exposing a huge attack surface > >in the place where it would hurt most and as the consolation we are offered > >basically "Ted is willing to fix holes when they are found". > For the context of static image attacks, anything that's found > _needs_ to be fixed regardless, and unless you can find some way to > actually prevent attacks on mounted filesystems that doesn't involve > a complete re-write of the filesystem drivers, then there's not much > we can do about it. Yes, unprivileged mounts expose an attack > surface, but so does userspace access to the network stack, and so > do a lot of other features that are considered essential in a modern > general purpose operating system. "X is exposes an attack surface. Y exposes a diferent attack surface. Y is considered important. Therefore X is important enough to implement it" Right... -- 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]
| From | Seth Forshee <seth.forshee@canonical.com> |
|---|---|
| Date | 2015-11-17 23:10 +0100 |
| Message-ID | <qvWBQ-2uT-1@gated-at.bofh.it> |
| In reply to | #1271655 |
On Tue, Nov 17, 2015 at 09:05:42PM +0000, Al Viro wrote: > On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote: > > > >This is absolutely insane, no matter how much LSM snake oil you slatter on > > >the whole thing. All of a sudden you are exposing a huge attack surface > > >in the place where it would hurt most and as the consolation we are offered > > >basically "Ted is willing to fix holes when they are found". None of the LSM changes are intended to protect against attacks from these sorts of attacks at all, so that's irrelevant. As I said before, I'm also working to find holes up front. That plus a commitment from the maintainer seems like a good start at least. What bar would you set for a given filesystem to be considered "safe enough"? > > For the context of static image attacks, anything that's found > > _needs_ to be fixed regardless, and unless you can find some way to > > actually prevent attacks on mounted filesystems that doesn't involve > > a complete re-write of the filesystem drivers, then there's not much > > we can do about it. Yes, unprivileged mounts expose an attack > > surface, but so does userspace access to the network stack, and so > > do a lot of other features that are considered essential in a modern > > general purpose operating system. > > "X is exposes an attack surface. Y exposes a diferent attack surface. > Y is considered important. Therefore X is important enough to implement it" > > Right... That isn't the argument he made. I would summarize the argument as, "Saying that X exposes an attack surface isn't by itself enough to reject X, otherwise we wouldn't expose anything (such as example Y)." You believe that the attack surface is too large, and that's understandable. Is it your opinion that this is a fundamental problem for an in-kernel filesystem driver, i.e. that we can never be confident enough in an in-kernel filesystem parser to allow untrusted data? If not, what would it take to establish a level of confidence that you would be comfortable with? -- 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]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-11-18 13:50 +0100 |
| Message-ID | <qwals-2Vg-21@gated-at.bofh.it> |
| In reply to | #1271691 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-11-17 17:01, Seth Forshee wrote: > On Tue, Nov 17, 2015 at 09:05:42PM +0000, Al Viro wrote: >> On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote: >> >>>> This is absolutely insane, no matter how much LSM snake oil you slatter on >>>> the whole thing. All of a sudden you are exposing a huge attack surface >>>> in the place where it would hurt most and as the consolation we are offered >>>> basically "Ted is willing to fix holes when they are found". > > None of the LSM changes are intended to protect against attacks from > these sorts of attacks at all, so that's irrelevant. > > As I said before, I'm also working to find holes up front. That plus a > commitment from the maintainer seems like a good start at least. What > bar would you set for a given filesystem to be considered "safe enough"? > >>> For the context of static image attacks, anything that's foun >>> _needs_ to be fixed regardless, and unless you can find some way to >>> actually prevent attacks on mounted filesystems that doesn't involve >>> a complete re-write of the filesystem drivers, then there's not much >>> we can do about it. Yes, unprivileged mounts expose an attack >>> surface, but so does userspace access to the network stack, and so >>> do a lot of other features that are considered essential in a modern >>> general purpose operating system. >> >> "X is exposes an attack surface. Y exposes a diferent attack surface. >> Y is considered important. Therefore X is important enough to implement it" >> >> Right... > > That isn't the argument he made. I would summarize the argument as, > "Saying that X exposes an attack surface isn't by itself enough to > reject X, otherwise we wouldn't expose anything (such as example Y)." It's good to see someone understood my meaning... > > You believe that the attack surface is too large, and that's > understandable. Is it your opinion that this is a fundamental problem > for an in-kernel filesystem driver, i.e. that we can never be confident > enough in an in-kernel filesystem parser to allow untrusted data? If > not, what would it take to establish a level of confidence that you > would be comfortable with? While I can't speak for Al's opinion on this, I would like to point out my earlier comment: > It's unfeasible from a practical standpoint to expect filesystems to > assume that stuff they write might change under them due to malicious > intent of a third party. We can't protect against everything, not without making the system completely unusable for general purpose computing. There is always some degree of trust involved in usage of a computer, the OS has to trust that the hardware works correctly, the administrator has to trust the OS to behave correctly, and the users have to trust the administrator. The administrator also needs to have at least some trust in the users, otherwise he shouldn't be allowing them to use the system. Perhaps we should have an option that can only be enabled on creation of the userns that would allow it to use regular kernel mounts, and without that option we default to only allowing FUSE and a couple of virtual filesystems (like /proc and devtmpfs).
[toc] | [prev] | [next] | [standalone]
| From | Seth Forshee <seth.forshee@canonical.com> |
|---|---|
| Date | 2015-11-18 15:40 +0100 |
| Message-ID | <qwc3T-48h-25@gated-at.bofh.it> |
| In reply to | #1272131 |
On Wed, Nov 18, 2015 at 07:46:53AM -0500, Austin S Hemmelgarn wrote: > On 2015-11-17 17:01, Seth Forshee wrote: > >On Tue, Nov 17, 2015 at 09:05:42PM +0000, Al Viro wrote: > >>On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote: > >> > >>>>This is absolutely insane, no matter how much LSM snake oil you slatter on > >>>>the whole thing. All of a sudden you are exposing a huge attack surface > >>>>in the place where it would hurt most and as the consolation we are offered > >>>>basically "Ted is willing to fix holes when they are found". > > > >None of the LSM changes are intended to protect against attacks from > >these sorts of attacks at all, so that's irrelevant. > > > >As I said before, I'm also working to find holes up front. That plus a > >commitment from the maintainer seems like a good start at least. What > >bar would you set for a given filesystem to be considered "safe enough"? > > > >>>For the context of static image attacks, anything that's foun > >>>_needs_ to be fixed regardless, and unless you can find some way to > >>>actually prevent attacks on mounted filesystems that doesn't involve > >>>a complete re-write of the filesystem drivers, then there's not much > >>>we can do about it. Yes, unprivileged mounts expose an attack > >>>surface, but so does userspace access to the network stack, and so > >>>do a lot of other features that are considered essential in a modern > >>>general purpose operating system. > >> > >>"X is exposes an attack surface. Y exposes a diferent attack surface. > >>Y is considered important. Therefore X is important enough to implement it" > >> > >>Right... > > > >That isn't the argument he made. I would summarize the argument as, > >"Saying that X exposes an attack surface isn't by itself enough to > >reject X, otherwise we wouldn't expose anything (such as example Y)." > It's good to see someone understood my meaning... > > > >You believe that the attack surface is too large, and that's > >understandable. Is it your opinion that this is a fundamental problem > >for an in-kernel filesystem driver, i.e. that we can never be confident > >enough in an in-kernel filesystem parser to allow untrusted data? If > >not, what would it take to establish a level of confidence that you > >would be comfortable with? > While I can't speak for Al's opinion on this, I would like to point > out my earlier comment: > > It's unfeasible from a practical standpoint to expect filesystems > to > assume that stuff they write might change under them due to > malicious > intent of a third party. So maybe the first requirement is that the user cannot modify the backing store directly while the device is mounted. > We can't protect against everything, not without making the system > completely unusable for general purpose computing. There is always > some degree of trust involved in usage of a computer, the OS has to > trust that the hardware works correctly, the administrator has to > trust the OS to behave correctly, and the users have to trust the > administrator. The administrator also needs to have at least some > trust in the users, otherwise he shouldn't be allowing them to use > the system. > > Perhaps we should have an option that can only be enabled on > creation of the userns that would allow it to use regular kernel > mounts, and without that option we default to only allowing FUSE and > a couple of virtual filesystems (like /proc and devtmpfs). I've considered the idea of something more global like a sysctl, or a per-filesystem knob in sysfs. I guess a per-container knob is another option, I'm not sure what interface we use to expose it though. -- 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]
| From | Austin S Hemmelgarn <ahferroin7@gmail.com> |
|---|---|
| Date | 2015-11-18 16:40 +0100 |
| Message-ID | <qwcZY-4Lu-5@gated-at.bofh.it> |
| In reply to | #1272228 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-11-18 09:30, Seth Forshee wrote:
> On Wed, Nov 18, 2015 at 07:46:53AM -0500, Austin S Hemmelgarn wrote:
>> On 2015-11-17 17:01, Seth Forshee wrote:
>>> On Tue, Nov 17, 2015 at 09:05:42PM +0000, Al Viro wrote:
>>>> On Tue, Nov 17, 2015 at 03:39:16PM -0500, Austin S Hemmelgarn wrote:
>>>>
>>>>>> This is absolutely insane, no matter how much LSM snake oil you slatter on
>>>>>> the whole thing. All of a sudden you are exposing a huge attack surface
>>>>>> in the place where it would hurt most and as the consolation we are offered
>>>>>> basically "Ted is willing to fix holes when they are found".
>>>
>>> None of the LSM changes are intended to protect against attacks from
>>> these sorts of attacks at all, so that's irrelevant.
>>>
>>> As I said before, I'm also working to find holes up front. That plus a
>>> commitment from the maintainer seems like a good start at least. What
>>> bar would you set for a given filesystem to be considered "safe enough"?
>>>
>>>>> For the context of static image attacks, anything that's foun
>>>>> _needs_ to be fixed regardless, and unless you can find some way to
>>>>> actually prevent attacks on mounted filesystems that doesn't involve
>>>>> a complete re-write of the filesystem drivers, then there's not much
>>>>> we can do about it. Yes, unprivileged mounts expose an attack
>>>>> surface, but so does userspace access to the network stack, and so
>>>>> do a lot of other features that are considered essential in a modern
>>>>> general purpose operating system.
>>>>
>>>> "X is exposes an attack surface. Y exposes a diferent attack surface.
>>>> Y is considered important. Therefore X is important enough to implement it"
>>>>
>>>> Right...
>>>
>>> That isn't the argument he made. I would summarize the argument as,
>>> "Saying that X exposes an attack surface isn't by itself enough to
>>> reject X, otherwise we wouldn't expose anything (such as example Y)."
>> It's good to see someone understood my meaning...
>>>
>>> You believe that the attack surface is too large, and that's
>>> understandable. Is it your opinion that this is a fundamental problem
>>> for an in-kernel filesystem driver, i.e. that we can never be confident
>>> enough in an in-kernel filesystem parser to allow untrusted data? If
>>> not, what would it take to establish a level of confidence that you
>>> would be comfortable with?
>> While I can't speak for Al's opinion on this, I would like to point
>> out my earlier comment:
>>> It's unfeasible from a practical standpoint to expect filesystems
>> to > assume that stuff they write might change under them due to
>> malicious > intent of a third party.
>
> So maybe the first requirement is that the user cannot modify the
> backing store directly while the device is mounted.
>
>> We can't protect against everything, not without making the system
>> completely unusable for general purpose computing. There is always
>> some degree of trust involved in usage of a computer, the OS has to
>> trust that the hardware works correctly, the administrator has to
>> trust the OS to behave correctly, and the users have to trust the
>> administrator. The administrator also needs to have at least some
>> trust in the users, otherwise he shouldn't be allowing them to use
>> the system.
>>
>> Perhaps we should have an option that can only be enabled on
>> creation of the userns that would allow it to use regular kernel
>> mounts, and without that option we default to only allowing FUSE and
>> a couple of virtual filesystems (like /proc and devtmpfs).
>
> I've considered the idea of something more global like a sysctl, or a
> per-filesystem knob in sysfs. I guess a per-container knob is another
> option, I'm not sure what interface we use to expose it though.
>
The most useful way I can see of implementing this would be to have an
option on container creation that controls whether kernel mounts are
allowed or not (possibly have it allow any of {no mounts, only FUSE
mounts, all mounts}), and then have a sysctl to set the default for
containers created without this option (and possibly one to force all
containers to ignore the option, and just use the default).
[toc] | [prev] | [next] | [standalone]
| From | bfields@fieldses.org (J. Bruce Fields) |
|---|---|
| Date | 2015-11-18 19:50 +0100 |
| Message-ID | <qwfXP-6Jq-5@gated-at.bofh.it> |
| In reply to | #1271604 |
On Tue, Nov 17, 2015 at 07:30:12PM +0000, Al Viro wrote: > On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote: > > > >_Static_ attacks, or change-image-under-mounted-fs attacks? > > To properly protect against attacks on mounted filesystems, we'd > > need some new concept of a userspace immutable file (that is, one > > where nobody can write to it except the kernel, and only the kernel > > can change it between regular access and this new state), and then > > have the kernel set an image (or block device) to this state when a > > filesystem is mounted from it (this introduces all kinds of other > > issues too however, for example stuff that allows an online fsck on > > the device will stop working, as will many un-deletion tools). > > > > The only other option would be to force the FS to cache all metadata > > in memory, and validate between the cache and what's on disk on > > every access, which is not realistic for any real world system. > > Doctor, it hurt when I do it... > > IOW, the other option is to refuse attempting this insanity. Fuse probably > can be handled, but being able to mount (with kernel-space drivera) an > arbitrary ext4 image is equivalent to being able to do anything and it's > going to stay that way for the forseeable future. What about the filesystems that desktop users commonly mount? (fat, isofs, udf?) --b. -- 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] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web