Date: Wed, 25 Nov 2015 13:14:25 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: freebsd-fs@freebsd.org Cc: John Case <case@SDF.ORG> Subject: Re: so ... what *are* we doing about byzantine ZFS send/recv streams ? Message-ID: <20151125131425.071dcae1@fabiankeil.de> In-Reply-To: <Pine.NEB.4.64.1511241620510.18893@faeroes.freeshell.org> References: <Pine.NEB.4.64.1511241620510.18893@faeroes.freeshell.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/4+sxasYsEnLHjNKG2zmr_jV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable John Case <case@SDF.ORG> wrote: > I was reading a thread on HN about ZFS[1] when someone from rsync.net=20 > commented that they support ZFS send/recv to their cloud platform.[2] >=20 > Someone else responded in that thread asking how they dealt with=20 > "byzantine streams", by which they meant a ZFS stream that has been=20 > corrupted on purpose so as to panic the receiver (or worse). >=20 > The rsync.net guy said they gave everyone their own zpool inside their ow= n=20 > bhyve so there isn't a big concern there - at worst "it might be a DOS=20 > attack". >=20 >=20 > So my questions: >=20 >=20 > 1. What, if anything, does FreeBSD 10.x do about "byzantine streams" and= =20 > is there any mitigation of this ? FreeBSD 10.x "does" nothing about this and merely inherits the issue from upstream. At the last OpenZFS developer summit the issue was briefly looked at and considered too complicated/expensive to solve completely. The people who looked at it mainly cared about the (Joyent) use case where the receiving and sending systems have trusted kernels, in which case signi= ng the streams is sufficient to workaround the issue. For details see: https://youtu.be/vKiJzj-vRYM For the "backup server" use case the issue can be mitigated by letting the clients access the storage through ggate (or iSCSI etc.) in which case the server does not have to parse the ZFS receive streams. If the clients additionally use geli they are also less likely to be successfully attacked by a compromised server. Example configurations: https://www.fabiankeil.de/talks/versteckter-block-speicher/mgp00029.html https://www.fabiankeil.de/talks/versteckter-block-speicher/mgp00030.html > 2. If I allow someone to ZFS send a arbitrary snapshot to me, does lockin= g=20 > them in a VM like the guy suggests a good solution ? Or is there still a= =20 > security/corruption threat there ? Whether or not it's a good solution depends on the use case. Being able to receive ZFS streams probably gives a motivated attacker complete control over the virtualized system in which case she's one VM vulnerability away from controlling the host system. Fabian --Sig_/4+sxasYsEnLHjNKG2zmr_jV Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZVpiEACgkQBYqIVf93VJ0NYgCeLqFbZ/bS8me+tPV4e19ptxPf VAgAoJt1KKPz44Pu+mv0JdVD06G0XXoD =xYbs -----END PGP SIGNATURE----- --Sig_/4+sxasYsEnLHjNKG2zmr_jV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151125131425.071dcae1>