[Libguestfs] [PATCH nbdkit] protocol: Implement NBD_OPT_GO.

[Nir Soffer]

On Mon, Aug 6, 2018 at 5:51 PM Daniel P. Berrangé <berrange at redhat.com>
wrote:

> On Mon, Aug 06, 2018 at 05:31:54PM +0300, Nir Soffer wrote:
> > On Mon, Aug 6, 2018 at 5:06 PM Eric Blake <eblake at redhat.com> wrote:
> >
> > > On 08/06/2018 02:54 AM, Richard W.M. Jones wrote:
> > > > On Sun, Aug 05, 2018 at 12:11:04AM +0300, Nir Soffer wrote:
> > > >> But we have a bug - server configure to allow access to "export",
> > > >> but allow access to the default empty "" export.
> > > >
> > > > nbdkit ignores the export name you pass in and always has done:
> > > >
> > > >
> > >
> https://github.com/libguestfs/nbdkit/blob/a2c4e88af503310892ebce6da3ac478beb47888a/src/connections.c#L626
> > > >
> > > > The -e option on the command line is only for advertizing an export
> > > > name to clients.  It is otherwise unused & unenforced.
> > >
> > > Agreed - it is not necessarily a bug for the server to permit the
> client
> > > to connect to different name(s) than what the server was told to
> advertise.
> > >
> > > >
> > > > One day we'll do something useful with it but we're not sure what.
> > >
> > > We might eventually reject clients that don't request the same export
> > > name as what was advertised, but that doesn't make the current behavior
> > > buggy (it only means that current clients shouldn't rely on a
> mismatched
> > > name always working).
> > >
> >
> > I does not make sense to allow access if the server was configured
> > with one export, and the user ask for another export. This is likely a
> bug
> > in user code or the code running nbdkit.
> >
> > If users do not want to specify the export, they run nbdkit with empty
> > export
> > name, and use empty export name in NBD_OPT_GO. If an export was
> > specified it should be handled in a strict way.
> >
> > Here is one use case that will be easily avoided by being strict about
> > export name:
> >
> > 1. application starts nbdkit on a port
> > 2. application reports port to user
> > 3. application time out, terminating nbdkit
> > 4. applcation starts nbdkit again on same port
> >    (maybe port range is cycled)
> > 5. application reports port to another user
> > 6. first user access nbdkit, accessing another user disk
> >
> > If we use random export name, and the server is strict, this failure
> > is not possible.
>
> Export name validation should not be considered a security feature, as
> the export name is not designated or treated as sensitive data.
>

I did not say this is a security issue.

If you want to prevent one user access other users' disks, whether by
> accidental or maliciously, you need to use TLS and validate clients
> certificates in the server, or use the new PSK credentials.


TLS will work but is not needed if you don't need a secure transport.

Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180806/29643b89/attachment.htm>