On Sat, Jan 23, 2021 at 05:44:48PM +0000, Graham Cobb wrote:
> 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.
So put the temporary mount point behind a mode 700 directory owned
by root, e.g.
umask 077
tmp="$(mktemp -d)"
mkdir "$tmp/mp"
mount -osubvolid=5 /dev/btrfs "$tmp/mp"
setfattr -n 'btrfs...' -v... "$tmp/mp"
umount "$tmp/mp"
rmdir "$tmp/mp" "$tmp"
This doesn't seem like a new problem, or a problem that doesn't already
have lots of good solutions.
Anyway I'm no longer favor of using an xattr this way for a number of
better reasons, so the point is moot.
> 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.
>
