Bug 214981 - ZFS happily and silently remounts any existing mount on pool import (POLA violation and security issue!)
Summary: ZFS happily and silently remounts any existing mount on pool import (POLA vio...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-01 14:12 UTC by VK
Modified: 2017-09-21 08:09 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description VK freebsd_triage 2016-12-01 14:12:12 UTC
When importing a pool with mountable datasets, they will always be mounted on their mountpoints even if those points are already mounted elsewhere. This includes even root (/).

Of course, unless you zpool import with, say, -R /mnt or -N.

However, the default is a huge violation of POLA, not to mention a huge security issue. ZFS on Linux, btw, will not remount existing mounts, will error out and complain.

I believe the defaults should be safe, non-destructive, non-astonishing, which is not the case here.
Comment 1 eborisch+FreeBSD 2016-12-10 05:27:55 UTC
Related: Bug #210222
Comment 2 VK freebsd_triage 2017-09-20 18:13:19 UTC
I now believe this problem should be taken more seriously. I'd also like to formally request the FreeBSD project to assign a CVE to this issue.

While I managed to train myself to always use -R or -N for zpool import, I now found out the hard way that if you have zfs_enable="YES" in rc.conf, which you would if you wanted your "local" datasets be mounted on boot, it has a side-effect of automatically importing and mounting datasets for any pool that becomes visible.

In other words, anythign you "plug in" that contains a ZFS pool. Say, a sneaky USB stick.

Merely unlocking geli'd drives will result with any pools on those drives being imported, datasets automounted, existing mountpoints remounted, root included, with zero warning, notification or complaint.

So technically, we don't even have the protection of import -R or -N. This is a security issue.
Comment 3 Andriy Gapon freebsd_committer 2017-09-20 18:34:09 UTC
(In reply to Vladimir Krstulja from comment #2)
FreeBSD does not import any pool that has not been manually imported first with 'zpool import'.  The root pool is the only exception for obvious reasons.
Comment 4 VK freebsd_triage 2017-09-20 21:01:30 UTC
(In reply to Andriy Gapon from comment #3)

Unfortunately, in my view, that doesn't change anything. One major problem is with ZFS receives, which is what hit me in this case. The server was receiving backup pools from production, a root pool included.

The obvious part is solved with import -R or -N, and giving -u to `zfs receive` so it doesn't mount received snapshots. All was well until after quite a long time I had to reboot the server. The act of unlocking the drives that contained the backup datasets, the very act of hitting enter on last geli passphrase imported and mounted everything it found, so I haven't had a chance to -R or -N.

The security problem in this is also through received datasets. One could argue that you have to trust data you receive, and I partially agree. It doesn't help that ZFS does not, with this, offer any safety net in an form of an ability to prevent automatic importing + mounting, from happening at all. Oh yeah, disable zfs service maybe. But totally not a solution.

Automatic, implicit, quiet, non-obvious remounts, especially of /, without the user explicitly stating it's okay to do so, should NEVER happen. Ever.

I really hope this issue will be treated as a serious problem.
Comment 5 Steven Hartland freebsd_committer 2017-09-20 21:32:31 UTC
I think the option your looking for is the canmount property.

At the end of the day there are loads of ways to break things from rm -rf or zfs destroy to pulling out a physical disk.

ZFS is a very powerful tool and it rightly assumes you know what your doing. 

Ensuring you’re aware of how receiving streams work and that unless told otherwise you want the file systems mounted is just part of your responsibility when you have that power.

Have I shot myself in the foot by receiving a stream without disabling mount, yes I have, do I believe ZFS should have prevented me from doing something so stupid absolutely not.
Comment 6 VK freebsd_triage 2017-09-20 21:40:13 UTC
Except you can't rm -rf /  . Why is it that you can't rm -rf /, but you can remount it with a random dataset that becomes available, with no questions asked, and no warnings given?

And it's simply not comparable. Running rm -rf is a deliberate, explicit action. Unlocking a geli provider and getting your root remounted is nowhere near that.

I'm sorry, but I don't accept that.

Plus, nothing would remove the power and flexibility of ZFS if it required confirmation or a --force flag, for such destructive actions.
Comment 7 Steven Hartland freebsd_committer 2017-09-21 08:09:44 UTC
Running zfs import is also a deliberate action and as Andriy already pointed out zfs doesn't automatically import pools that have not already been manually imported.

If you don't want the filesystems mounted just set canmount=off or canmount=noauto.