Date: Wed, 6 Nov 2019 17:02:14 -0700 From: Alan Somers <asomers@freebsd.org> To: Jan Behrens <jbe-mlist@magnetkern.de> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: ZFS snapdir readability (Crosspost) Message-ID: <CAOtMX2huHZcXHH%2B=3Bx7hX_p9udJ2acOX%2BZL8vW=pjqbe6mOAA@mail.gmail.com> In-Reply-To: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 6, 2019 at 4:46 PM Jan Behrens <jbe-mlist@magnetkern.de> wrote: > Dear all, > > I'd like to crosspost an issue I have with the .zfs/snapdir directory. > My original post was in freebsd-questions@freebsd.org but apparently > nobody could answer my questions there. Since the topic is quite ZFS > specific, I wonder if this is the better place to ask my questions. > > Original subject: > ZFS snapdir readability - feature request or security issue? > > Original date: Sun, 27 Oct 2019 12:27:28 +0100 > > 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 > Your analysis of the snapdir is correct. Setting it to hidden doesn't make it inaccessible. That's not unique to FreeBSD, however. I believe it's common to all ZFS implementations (I just double checked on Oracle Solaris). Also, the problem isn't unique to ZFS. Any backup system would have the same problem, as long as users are allowed to access the backups directly. And in fact, Bob could've directly observed Alice's id_rsa file before she changed it. So I don't think this should be considered a security vulnerability. The best course for Alice would be to consider her id_rsa as compromised as soon as she notices the problem, and delete it. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2huHZcXHH%2B=3Bx7hX_p9udJ2acOX%2BZL8vW=pjqbe6mOAA>