Re: [Nbd] Easier use, authentication

[Wouter Verhelst <w@...112...>]

On Mon, Sep 26, 2011 at 03:25:14AM -0400, Christian Jaeger wrote:
> (I've accidentally first sent this as a private reply instead of to
> the list; I need to be more careful using the gmail web UI.)
> 
> 2011/9/25 Wouter Verhelst <w@...112...>:
> > Can you explain that a bit? I don't see how you could make that easier,
> > to be honest, but ideas are always welcome.
> 
> I haven't really thought it through either yet, mostly because I first
> wanted to check what existing solutions I might have missed. So these
> are half-baked ideas:
> 
> One use case I imagine (maybe the one that solves it for me) is to use
> ssh as command connection to start a server instance. Like, I run a
> script on the client which runs "ssh me@...945... nbd-server filepath
> some-options" (probably non-root user; might even be a restricted
> shell only allowing nbd-server with certain paths/arguments to be
> called).

You could theoretically do that with the command-line mode of
nbd-server, though you'll miss out on a number of features then; one of
them being the name-based exports.

However, I fail to see why this would be useful; what's so wrong with a
configuration file?

> This uses a more secure connection to do the most sensitive
> decisions like which file to serve, and the server system could thus
> be more trusty on what to allow. The idea is not to need any
> configuration file at all on the server. A secret value (random
> string) for the challenge-response authentication could be passed over
> this ssh connection too, read from stdin (to avoid showing it up in
> the process table).
> 
> On the client, the script would need to run nbd-client in a way that
> allocates the next free nbd device automatically, and tells which it
> is (similar to "losetup -fs file"). IIRC that's not possible
> currently, but I might be wrong, as mentioned I haven't started to try
> to script it yet.

Yeah, that bit is a bit painful currently. A few years back I suggested
to Paul that he implement some scheme whereby there would be an
'nbd master' device node on which you could ask for a /dev/nbdX node to
be allocated, but I don't think anything has come from it.

I could imagine a scheme whereby nbd-client checks for
/sys/block/nbdX/pid, but that's going to be racy so would need some
locking; this could get pretty ugly.

[...]
> > TCP hijacking isn't exactly difficult,
> 
> Unless the ARP mapping table is set up statically on both server and
> guest (correct?). Even though that would be a pain to maintain, it
> would at least make it *possible* to prevent men in the middle.
> 
> An idea might also be to send checksums with each message plus a
> secret and serial number, to make men in the middle impossible. Of
> course the question then becomes how much cheaper that can be than
> full-blown encryption (including checksumming).

Indeed. I don't think that would buy us much.

> My fileserver with Atom D510 @ 1.66GHz hashes about 102 MB/sec with
> "openssl sha1"; it transfers about 90 MB/s traffic using netcat over
> the gbit ethernet (not sure why not more, would have to check); and
> transfers about 15 MB/s over ssh with compression off and using
> blowfish encryption.  These numbers seem to make this idea quite
> attractive; although this test isn't fair since hash setup costs for
> each of the smaller messages will cost cpu not included here, and sha1
> isn't really secure anymore (the newer hashes are about half as fast
> in openssl).

Right.

The code in the 'auth' branch uses a pure-C implementation of the SHA-2
series of algorithms; I believe the actual hash used is SHA-512, but I
could be mistaken. But if we're going to do authentication only, and not
encryption, then hash speed isn't very important (we'll only do one hash
at the beginning of the connection)

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a