From owner-freebsd-fs@freebsd.org Thu Nov 7 00:20:38 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 D69EC17D95A for ; Thu, 7 Nov 2019 00:20:38 +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 477kZZ5KBPz3LcS; Thu, 7 Nov 2019 00:20:38 +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 CCE72A9D4; Thu, 7 Nov 2019 00:20:27 +0000 (UTC) Date: Thu, 7 Nov 2019 01:20:27 +0100 From: Jan Behrens To: freebsd-fs@freebsd.org Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191107012027.9639f3a9dda1941518358a52@magnetkern.de> In-Reply-To: References: <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: 477kZZ5KBPz3LcS X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Thu, 07 Nov 2019 00:20:38 -0000 > On Wed, Nov 6, 2019 at 4:46 PM Jan Behrens wrote: > > > I recently noticed that all ZFS filesystems in FreeBSD allow access to > > the .zfs directory (snapdir) for all users of the system. On Wed, 6 Nov 2019 17:02:14 -0700 Alan Somers wrote: > 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). I already suspected that this might be an issue originating from ZFS itself (and not be FreeBSD specific). Thank you for the research (I don't have a Solaris system at hand ;-) > 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. My problem here is that with most (or maybe even all) other backup systems, I would be able to restrict ordinary users from accessing all backups. So I consider this problem to be pretty much unique to ZFS (unless I misunderstood your point?) > 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 I already foresaw this argument and mentioned a possible counter-argument: > > 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. There could be several examples (other than an ssh key file) where someone wants to restrict access to a previously publicly readable file (whether it was deliberately publicly readable or accidentally publicly readable). Regards Jan