Re: [RFC][PATCH V5] btrfs: preferred_metadata: preferred device for metadata

From: Graham Cobb <g.btrfs@cobb.uk.net>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: Goffredo Baroncelli <kreijack@inwind.it>,
	Josef Bacik <josef@toxicpanda.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [RFC][PATCH V5] btrfs: preferred_metadata: preferred device for metadata
Date: Sat, 23 Jan 2021 17:44:48 +0000	[thread overview]
Message-ID: <24522e9a-8cfb-73ab-2332-c7e0c6b9677c@cobb.uk.net> (raw)
In-Reply-To: <20210123172118.GJ28049@hungrycats.org>

On 23/01/2021 17:21, Zygo Blaxell wrote:
> On Sat, Jan 23, 2021 at 02:55:52PM +0000, Graham Cobb wrote:
>> On 22/01/2021 22:42, Zygo Blaxell wrote:
>> ...
>>>> So the point is: what happens if the root subvolume is not mounted ?
>>>
>>> It's not an onerous requirement to mount the root subvol.  You can do (*)
>>>
>>> 	tmp="$(mktemp -d)"
>>> 	mount -osubvolid=5 /dev/btrfs "$tmp"
>>> 	setfattr -n 'btrfs...' -v... "$tmp"
>>> 	umount "$tmp"
>>> 	rmdir "$tmp"
>>
>> No! I may have other data on that disk which I do NOT want to become
>> accessible to users on this system (even for a short time). As a simple
>> example, imagine, a disk I carry around to take emergency backups of
>> other systems, but I need to change this attribute to make the emergency
>> backup of this system run as quickly as possible before the system dies.
>> Or a disk used for audit trails, where users should not be able to
>> modify their earlier data. Or where I suspect a security breach has
>> occurred. I need to be able to be confident that the only data
>> accessible on this system is data in the specific subvolume I have mounted.
> 
> Those are worthy goals, but to enforce them you'll have to block or filter
> the mount syscall with one of the usual sandboxing/container methods.
> 
> If you have that already set up, you can change root subvol xattrs from
> the supervisor side.  No users will have access if you don't give them
> access to the root subvol or the mount syscall on the restricted side
> (they might also need a block device FD belonging to the filesystem).
> 
> If you don't have the sandbox already set up, then root subvol access
> is a thing your users can already do, and it may be time to revisit the
> assumptions behind your security architecture.

I'm not talking about root. I mean unpriv'd users (who can't use mount)!
If I (as root) mount the whole disk, those users may be able to read or
modify files from parts of that disk to which they should not have
access. That may be  why I am not mounting the whole disk in the first
place.

I gave a few very simple examples, but I can think of many more cases
where a disk may contain files which users might be able to access if
the disk was mounted (maybe the disk has subvols used by many different
systems but UIDs are not coordinated, or ...).  And, of course, if they
can open a FD during the brief time it is mounted, they can stop it
being unmounted again.

No. If I have chosen to mount just a subvol, it is because I don't want
to mount the whole disk.