so ... what *are* we doing about byzantine ZFS send/recv streams ?

[Fabian Keil]

John Case <case at SDF.ORG> wrote:

> I was reading a thread on HN about ZFS[1] when someone from rsync.net 
> commented that they support ZFS send/recv to their cloud platform.[2]
> 
> Someone else responded in that thread asking how they dealt with 
> "byzantine streams", by which they meant a ZFS stream that has been 
> corrupted on purpose so as to panic the receiver (or worse).
> 
> The rsync.net guy said they gave everyone their own zpool inside their own 
> bhyve so there isn't a big concern there - at worst "it might be a DOS 
> attack".
> 
> 
> So my questions:
> 
> 
> 1. What, if anything, does FreeBSD 10.x do about "byzantine streams" and 
> 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 signing
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 locking 
> them in a VM like the guy suggests a good solution ?  Or is there still a 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20151125/57bc26fe/attachment.bin>