Re: Security implications of btrfs receive?

On 2016-09-12 16:25, Chris Murphy wrote: On Mon, Sep 12, 2016 at 5:24 AM, Austin S. Hemmelgarn wrote: After device discovery, specify UUID= instead of a device node. Oh yeah good point, -U --uuid is also doable. I'm not sure what the benefit is of using sysfs to delete

Re: Security implications of btrfs receive?

On Mon, Sep 12, 2016 at 5:24 AM, Austin S. Hemmelgarn wrote: > > After device discovery, specify UUID= instead of a device node. Oh yeah good point, -U --uuid is also doable. I'm not sure what the benefit is of using sysfs to delete a device's node after umounting. If the

Re: Security implications of btrfs receive?

On 2016-09-09 14:58, Chris Murphy wrote: On Thu, Sep 8, 2016 at 5:48 AM, Austin S. Hemmelgarn wrote: On 2016-09-07 15:34, Chris Murphy wrote: I like the idea of matching WWN as part of the check, with a couple of caveats: 1. We need to keep in mind that in some

Re: Security implications of btrfs receive?

On Fri, Sep 9, 2016 at 12:58 PM, Chris Murphy wrote: > > It should work better than it does because it works well for LVM and > mdadm arrays. > > I think what's going on is the DE's mounter (udisksd) tries to mount > each Btrfs device node, even though those nodes make

Re: Security implications of btrfs receive?

On Thu, Sep 8, 2016 at 5:48 AM, Austin S. Hemmelgarn wrote: > On 2016-09-07 15:34, Chris Murphy wrote: > I like the idea of matching WWN as part of the check, with a couple of > caveats: > 1. We need to keep in mind that in some environments, this can be spoofed >

Re: Security implications of btrfs receive?

On 2016-09-09 12:33, David Sterba wrote: On Wed, Sep 07, 2016 at 03:08:18PM -0400, Austin S. Hemmelgarn wrote: On 2016-09-07 14:07, Christoph Anton Mitterer wrote: On Wed, 2016-09-07 at 11:06 -0400, Austin S. Hemmelgarn wrote: This is an issue with any filesystem, Not really... any other

Re: Security implications of btrfs receive?

On 2016-09-09 12:18, David Sterba wrote: On Wed, Sep 07, 2016 at 07:58:30AM -0400, Austin S. Hemmelgarn wrote: On 2016-09-06 13:20, Graham Cobb wrote: Thanks to Austin and Duncan for their replies. On 06/09/16 13:15, Austin S. Hemmelgarn wrote: On 2016-09-05 05:59, Graham Cobb wrote: Does

Re: Security implications of btrfs receive?

On Wed, Sep 07, 2016 at 03:08:18PM -0400, Austin S. Hemmelgarn wrote: > On 2016-09-07 14:07, Christoph Anton Mitterer wrote: > > On Wed, 2016-09-07 at 11:06 -0400, Austin S. Hemmelgarn wrote: > >> This is an issue with any filesystem, > > Not really... any other filesystem I'd know (not sure about

Re: Security implications of btrfs receive?

On Wed, Sep 07, 2016 at 07:58:30AM -0400, Austin S. Hemmelgarn wrote: > On 2016-09-06 13:20, Graham Cobb wrote: > > Thanks to Austin and Duncan for their replies. > > > > On 06/09/16 13:15, Austin S. Hemmelgarn wrote: > >> On 2016-09-05 05:59, Graham Cobb wrote: > >>> Does the "path" argument of

Re: Security implications of btrfs receive?

On 2016-09-07 15:34, Chris Murphy wrote: On Wed, Sep 7, 2016 at 1:08 PM, Austin S. Hemmelgarn wrote: I think I covered it already in the last thread on this, but the best way I see to fix the whole auto-assembly issue is: 1. Stop the damn auto-scanning of new devices on

Re: Security implications of btrfs receive?

On Wed, Sep 07, 2016 at 08:07:59PM +0200, Christoph Anton Mitterer wrote: > Even other multi-device containers (LVM, MD) don't at least corrupt > your data like it allegedly can happen with btrfs. LVM and MD also check sequence numbers and timestamps. You can't just guess the UUID, you need a

Re: Security implications of btrfs receive?

On Wed, Sep 7, 2016 at 1:08 PM, Austin S. Hemmelgarn wrote: > I think I covered it already in the last thread on this, but the best way I > see to fix the whole auto-assembly issue is: > 1. Stop the damn auto-scanning of new devices on hot-plug. The scanning > should be

Re: Security implications of btrfs receive?

On 2016-09-07 14:07, Christoph Anton Mitterer wrote: On Wed, 2016-09-07 at 11:06 -0400, Austin S. Hemmelgarn wrote: This is an issue with any filesystem, Not really... any other filesystem I'd know (not sure about ZFS) keeps working when there are UUID collisions... or at least it won't cause

Re: Security implications of btrfs receive?

On Wed, 2016-09-07 at 11:06 -0400, Austin S. Hemmelgarn wrote: > This is an issue with any filesystem, Not really... any other filesystem I'd know (not sure about ZFS) keeps working when there are UUID collisions... or at least it won't cause arbitrary corruptions, which then in the end may even

Re: Security implications of btrfs receive?

On 2016-09-07 12:10, Graham Cobb wrote: On 07/09/16 16:20, Austin S. Hemmelgarn wrote: I should probably add to this that you shouldn't be accepting send/receive data streams from untrusted sources anyway. While it probably won't crash your system, it's not intended for use as something like a

Re: Security implications of btrfs receive?

On 07/09/16 16:06, Austin S. Hemmelgarn wrote: > It hasn't, because there's not any way it can be completely fixed. This > particular case is an excellent example of why it's so hard to fix. To > close this particular hole, BTRFS itself would have to become aware of > whether whoever is running

Re: Security implications of btrfs receive?

On 07/09/16 16:20, Austin S. Hemmelgarn wrote: > I should probably add to this that you shouldn't be accepting > send/receive data streams from untrusted sources anyway. While it > probably won't crash your system, it's not intended for use as something > like a network service. If you're

Re: Security implications of btrfs receive?

On 2016-09-07 07:58, Austin S. Hemmelgarn wrote: On 2016-09-06 13:20, Graham Cobb wrote: Thanks to Austin and Duncan for their replies. On 06/09/16 13:15, Austin S. Hemmelgarn wrote: On 2016-09-05 05:59, Graham Cobb wrote: Does the "path" argument of btrfs-receive mean that *all* operations

Re: Security implications of btrfs receive?

On 2016-09-07 10:41, Christoph Anton Mitterer wrote: On Tue, 2016-09-06 at 18:20 +0100, Graham Cobb wrote: they know the UUID of the subvolume? Unfortunately, btrfs seems to be pretty problematic when anyone knows your UUIDs... This is an issue with any filesystem, it is just a bigger issue

Re: Security implications of btrfs receive?

On 2016-09-07 10:44, Christoph Anton Mitterer wrote: On Wed, 2016-09-07 at 07:58 -0400, Austin S. Hemmelgarn wrote: if you want proper security you should be using a real container system Won't these probably use the same filesystems? That depends on how it's set up. Most container software

Re: Security implications of btrfs receive?

On Wed, 2016-09-07 at 07:58 -0400, Austin S. Hemmelgarn wrote: > if you want proper security you should > be  > using a real container system Won't these probably use the same filesystems? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature

Re: Security implications of btrfs receive?

On Tue, 2016-09-06 at 18:20 +0100, Graham Cobb wrote: > they know the UUID of the subvolume? Unfortunately, btrfs seems to be pretty problematic when anyone knows your UUIDs... Look for my thread "attacking btrfs filesystems via UUID collisions?" in the list archives. From accidental corruptions

Re: Security implications of btrfs receive?

On 2016-09-06 13:20, Graham Cobb wrote: Thanks to Austin and Duncan for their replies. On 06/09/16 13:15, Austin S. Hemmelgarn wrote: On 2016-09-05 05:59, Graham Cobb wrote: Does the "path" argument of btrfs-receive mean that *all* operations are confined to that path? For example, if a UUID

Re: Security implications of btrfs receive?

Thanks to Austin and Duncan for their replies. On 06/09/16 13:15, Austin S. Hemmelgarn wrote: > On 2016-09-05 05:59, Graham Cobb wrote: >> Does the "path" argument of btrfs-receive mean that *all* operations are >> confined to that path? For example, if a UUID or transid is sent which >> refers

Re: Security implications of btrfs receive?

On 2016-09-05 05:59, Graham Cobb wrote: Does anyone know of a security analysis of btrfs receive? I'm not a developer, and definitely not a security specialist, just a security minded sysadmin who has some idea what's going on, but I can at least try and answer this. I assume that just using

Re: Security implications of btrfs receive?

Graham Cobb posted on Mon, 05 Sep 2016 10:59:30 +0100 as excerpted: > Lastly, even if receive is designed to be very secure, it is possible > that it could trigger/use code paths in the btrfs kernel code which are > not normally used during normal file operations and so could trigger > bugs not

Security implications of btrfs receive?

Does anyone know of a security analysis of btrfs receive? I assume that just using btrfs receive requires root (is that so?). But I was thinking of setting up a backup server which would receive snapshots from various client systems, each in their own path, and I wondered how much the security