From owner-freebsd-fs@freebsd.org Wed Nov 6 23:46:54 2019 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 96EA117C2F0 for ; Wed, 6 Nov 2019 23:46:54 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Received: from sapphire.magnetkern.de (sapphire.magnetkern.de [185.228.139.199]) by mx1.freebsd.org (Postfix) with ESMTP id 477jqd2r0dz3JXH for ; Wed, 6 Nov 2019 23:46:53 +0000 (UTC) (envelope-from jbe-mlist@magnetkern.de) Received: from titanium (p57A35420.dip0.t-ipconnect.de [87.163.84.32]) by sapphire.magnetkern.de (Postfix) with ESMTPSA id E25ECA9AE for ; Wed, 6 Nov 2019 23:46:35 +0000 (UTC) Date: Thu, 7 Nov 2019 00:46:35 +0100 From: Jan Behrens To: freebsd-fs@freebsd.org Subject: ZFS snapdir readability (Crosspost) Message-Id: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 477jqd2r0dz3JXH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jbe-mlist@magnetkern.de designates 185.228.139.199 as permitted sender) smtp.mailfrom=jbe-mlist@magnetkern.de X-Spamd-Result: default: False [-1.81 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; DMARC_NA(0.00)[magnetkern.de]; MV_CASE(0.50)[]; IP_SCORE(-0.12)[asn: 197540(-0.59), country: DE(-0.01)]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[32.84.163.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:197540, ipnet:185.228.136.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 23:46:54 -0000 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