From owner-freebsd-fs@freebsd.org Wed Nov 20 15:34:50 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 B1EBF1B9FD9 for ; Wed, 20 Nov 2019 15:34:50 +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 47J6FQ0wx6z3xfQ; Wed, 20 Nov 2019 15:34:49 +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 53D261FDE4; Wed, 20 Nov 2019 15:34:38 +0000 (UTC) Date: Wed, 20 Nov 2019 16:34:37 +0100 From: Jan Behrens To: Borja Marcos Cc: Mike Tancsa , Alan Somers , freebsd-fs Subject: Re: ZFS snapdir readability (Crosspost) Message-Id: <20191120163437.691abd369ab9c0a6d7d45ff2@magnetkern.de> In-Reply-To: References: <20191107004635.c6d2e7d464d3d556a0d87465@magnetkern.de> <9B22AD46-BE87-4305-9638-74D23AD4C8CA@sarenet.es> <261FE331-EC5C-48C8-9249-9BCBF887CE38@sarenet.es> <913f7040-6e38-452d-6187-e17fae63b652@sentex.net> <20191120144041.7f916360dc0c69bf509c9bd1@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=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47J6FQ0wx6z3xfQ 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 [-0.74 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.64)[-0.643,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[magnetkern.de]; NEURAL_HAM_LONG(-0.61)[-0.615,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; IP_SCORE(0.22)[ipnet: 185.228.136.0/22(1.74), asn: 197540(-0.65), 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, 20 Nov 2019 15:34:50 -0000 On Wed, 20 Nov 2019 16:02:14 +0100 Borja Marcos wrote: > > On 20 Nov 2019, at 14:40, Jan Behrens wrote: > > > > On Wed, 20 Nov 2019 08:24:43 -0500 > > Mike Tancsa wrote: > > > >> Actually, thats all I am advocating for-- settings perms on the > >> accessibility of the snapshot. ie instead of the "invisibility" feature, > >> change it to an "inaccessible" feature. > >> > >> ---Mike > > > > This would solve the security problem, but only as long as snapshots are > > never mounted. Once they are mounted (unless you can specify the > > directory where they are mounted), unprivileged users could still > > access files they should not be allowed to access. > > > > A better solution would be to specify user, group, and modes > > (e.g. root:root 700) when mounting or auto-mounting snapshots. > > At least it’s a different problem. Mounting a snapshot *intentionally* could be > something similar to recovering a backup. What poses a serious issue in my > opinion is that the system *does* mount them automatically. > > Borja. > Security vulnerabilities during backup recovery (e.g. when recovering part of the backup but being forced to expose other data as well when mounting the system) are still security vulnerabilities. Of course limiting the security vulnerabilities to certain moments (partial backup recovery) is a nice step forward, but an even better solution would be to avoid security vulnerabilities at all times. The latter requires to either (a) never mount snapshots ever, or (b) only mount snapshots when they are to be *completely* restored, or (c) be able to specify the user, group, and mode (unless 700 by default) when mounting or auto-mounting the snapshots, or (d) be able to specify a mount point such that the mount point can be within a directory that is not +x for everyone. Regards, Jan