Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Oct 2019 12:27:28 +0100
From:      Jan Behrens <jbe-mlist@magnetkern.de>
To:        freebsd-questions@freebsd.org
Subject:   ZFS snapdir readability - feature request or security issue?
Message-ID:  <20191027122728.8de0e914dcb2d72d13d682d6@magnetkern.de>

next in thread | raw e-mail | index | archive | help
Dear all,

I recently noticed that all ZFS filesystems in FreeBSD allow access to
the .zfs directory (snapdir) for all users of the system. It is
possible to hide that directory using the snapdir option:

snapdir=hidden | visible
  Controls whether the .zfs directory is hidden or visible in the root
  of the file system as discussed in the "Snapshots" section. The
  default value is hidden.

However, setting snapdir=hidden will only "hide" the directory from
"ls". It is still possible to access that directory, also as a
non-privileged user!

It seems to be impossible to restrict access to this directory. Calling
chmod 700 /.zfs results in "chmod: /.zfs: Operation not supported".

Given the immutability of snapshots, the directories and files will
have access rights from the point in time when the snapshot was taken.
Considering a system that creates snapshots regularly (e.g. for backup
or replication purposes), this could lead to security issues, as I
would like to illustrate with the following example:

Consider a user (Alice) who accidentally created a file
/usr/home/alice/.ssh/id_rsa as publicly readible, but who notices
shortly after that this was a mistake. Alice fixes her mistake by
calling: chmod 600 /usr/home/alice/.ssh/id_rsa

If in the meantime a snapshot zroot/usr/home@2019-10-27 was taken,
which is intended to be kept for a longer time, then Bob will be able
to access Alice's private SSH key through the
file /usr/home/.zfs/snapshot/2010-10-27/alice/.ssh/id_rsa

As far as I understand, there is no (clean) way to prohibit this, except
deleting the whole snapshot (which might not be desirable in all
scenarios). Note that:

su - root
chmod 700 /usr/home/.zfs                     => Operation not supported
chmod 700 /usr/home/.zfs/snapshot            => Operation not supported
chmod 700 /usr/home/.zfs/snapshot/2019-10-27 => Read-only file system

Of course, one could argue that Alice shouldn't have made the mistake
in the first place. Nonetheless, I consider it to be a security issue
if regular snapshots cause files which were once publicly readable to
be always readable (as long as certain snapshots exist). Moreover, a
user might want to deliberatly block access to a file that was
intendedly public before.

One (dirty) workaround I was able to figure out is to do a
mount_nullfs /var/empty /usr/home/.zfs which results in the following
behavior:
- /usr/home/.zfs is still hidden
- /usr/home/.zfs is empty for all users (root and non-privileged users)

I was able to improve this by doing:
mkdir -p /usr/home/protected/snapshot
chmod 700 /usr/home/protected
mount_nullfs /usr/home/.zfs/snapshot /usr/home/protected/snapshot
mount_nullfs /var/empty /usr/home/.zfs

This way, the root user can access the snapshot directory
through /usr/home/protected/snapshot while all other users should
(hopefully) not be able to gain access to snapshot data. This
workaround, however, has several drawbacks:

- Considering a larger number of ZFS filesystems on an average system
  (my system came with 14 file systems by default), this will bloat the
  output of "mount" and easily cause confusion.
- There can be race conditions when mounting a previously unmounted ZFS
  filesystem, such that for a small moment (after mounting the ZFS file
  system and before doing the nullfs mount), a malicious user could
  access the hidden .zfs directory.
- Using the default commands, it is likely to accidentally forget the
  nullfs mount and leave the snapdir exposed to non-privileged users.

Is there any other method to prohibit non-privileged users from
accessing the ZFS snapdir? If not, I would propose to add one. I'm not
even sure if this is a feature request or rather fixing a security
vulnerability as explained in the Alice & Bob example above.


Kind regards,
Jan Behrens



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191027122728.8de0e914dcb2d72d13d682d6>