[Libguestfs] [libnbd PATCH] RFC: fuzzing: Break up handshake into more steps
Give the fuzzer a few more points to experiment with added branching by explicitly using opt mode. --- I'm not quite sure whether the fuzzer is able to synthesize specific API calls from the client side; but if it can, letting the client specifically enter the NEGOTIATING state may allow the fuzzer to spot other nbd_opt_* API call chains that could provoke odd interactions, which would be completely missed when sticking with the default of skipping opt mode. fuzzing/libnbd-fuzz-wrapper.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fuzzing/libnbd-fuzz-wrapper.c b/fuzzing/libnbd-fuzz-wrapper.c index 7e390558..e7cf7fe9 100644 --- a/fuzzing/libnbd-fuzz-wrapper.c +++ b/fuzzing/libnbd-fuzz-wrapper.c @@ -200,7 +200,10 @@ client (int sock) nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION); /* This tests the handshake phase. */ + nbd_set_opt_mode (nbd, true); nbd_connect_socket (nbd, sock); + nbd_opt_info (nbd); + nbd_opt_go (nbd); length = nbd_get_size (nbd); -- 2.37.3 ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Parameter 'encrypt.key-secret' is required for cipher for virt-ls
On Thu, Oct 06, 2022 at 03:33:34PM +0100, Richard W.M. Jones wrote: > > > Could you please provide an example on how to get such an encrypted disk > > > mounted? > > > > My understanding is that libguestfs (and guestfs-tools) do not currently > > support the kind of encrypted disk where the encryption is implemented > > by QEMU, at the qcow2 layer. > > I think the only sane way to do this at the moment is to open the > image first using qemu-nbd and then connect libguestfs to the NBD > socket. In other words something like this: > > $ qemu-nbd --object secret,id=sec0,data=secretpassword \ >--image-opts > driver=qcow2,file.filename=machine1.qcow2,encrypt.format=luks,encrypt.key-secret=sec0 > \ > -t -k /tmp/socket & > $ guestfish --format=raw -a 'nbd+unix:///?socket=/tmp/socket' -i It may also be possible to use qemu-storage-daemon's fuse export to access the unencrypted contents without going through NBD; but the point remains the same of having qemu do the translation into a format that guestfish can access. I'm less familiar with the command line needed to set up a q-s-d fuse export; a quick google search found https://www.lightnetics.com/topic/31893/exporting-block-devices-as-raw-image-files-with-fuse which might be helpful in your explorations. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Parameter 'encrypt.key-secret' is required for cipher for virt-ls
On Thu, Oct 06, 2022 at 12:16:36PM +0200, Laszlo Ersek wrote: > On 10/05/22 16:06, Do Re wrote: > > Hello all, > > > > background: One of my VM stopped working - on startup, I get the message > > "No bootable device" in the virtual machine. > > > > I would like to inspect the corresponding image with libguestfs-tools. > > > > However, I don't know how to pass the encryption key to the tool. For > > example: > > > > virt-ls -a /opt/vm_witherror/machine1.qcow2 / > > libguestfs: trace: set_verbose true > > libguestfs: trace: set_verbose = 0 > > libguestfs: create: flags = 0, handle = 0x5645c40d6b00, program = virt-ls > > libguestfs: trace: add_drive "/opt/vm_witherror/machine1.qcow2" > > "readonly:true" > > libguestfs: creating COW overlay to protect original drive content > > libguestfs: trace: get_tmpdir > > libguestfs: trace: get_tmpdir = "/tmp" > > libguestfs: trace: disk_create "/tmp/libguestfsxECmri/overlay1.qcow2" > > "qcow2" -1 "backingfile:/opt/vm_witherror/machine1.qcow2" > > libguestfs: command: run: qemu-img > > libguestfs: command: run: \ create > > libguestfs: command: run: \ -f qcow2 > > libguestfs: command: run: \ -o backing_file=/opt/vm_witherror/machine1.qcow2 > > libguestfs: command: run: \ /tmp/libguestfsxECmri/overlay1.qcow2 > > qemu-img: /tmp/libguestfsxECmri/overlay1.qcow2: Parameter > > 'encrypt.key-secret' is required for cipher > > Could not open backing image. > > libguestfs: error: qemu-img: /tmp/libguestfsxECmri/overlay1.qcow2: > > qemu-img exited with error status 1, see debug messages above > > libguestfs: trace: disk_create = -1 (error) > > libguestfs: trace: add_drive = -1 (error) > > libguestfs: trace: close > > libguestfs: closing guestfs handle 0x5645c40d6b00 (state 0) > > libguestfs: command: run: rm > > libguestfs: command: run: \ -rf /tmp/libguestfsxECmri > > > > > > Could you please provide an example on how to get such an encrypted disk > > mounted? > > My understanding is that libguestfs (and guestfs-tools) do not currently > support the kind of encrypted disk where the encryption is implemented > by QEMU, at the qcow2 layer. I think the only sane way to do this at the moment is to open the image first using qemu-nbd and then connect libguestfs to the NBD socket. In other words something like this: $ qemu-nbd --object secret,id=sec0,data=secretpassword \ --image-opts driver=qcow2,file.filename=machine1.qcow2,encrypt.format=luks,encrypt.key-secret=sec0 \ -t -k /tmp/socket & $ guestfish --format=raw -a 'nbd+unix:///?socket=/tmp/socket' -i Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [libnbd PATCH] api: Add nbd_[aio_]opt_starttls
On Tue, Oct 04, 2022 at 07:51:18AM -0500, Eric Blake wrote:
> Very similar to the recent addition of nbd_opt_structured_reply, with
> the new nbd_opt_starttls() finally giving us fine-grained control over
> NBD_OPT_STARTTLS, and allowing productive handshaking with a server in
> SELECTIVETLS mode.
>
> With this patch, it is now easy to reproduce the scenario of nbdkit's
> CVE-2021-3716, where a plaintext meddler-in-the-middle attacker could
> cause client denial of service when a --tls=on server failed to reset
> state after NBD_OPT_STARTTLS. This also exposed the fact that nbdkit
> was not gracefully handling NBD_OPT_INFO from a plaintext client
> connecting to a --tls=require server; the testsuite is skipped unless
> using a fixed nbdkit (v1.33.2 or later).
I guess so. It does seem complicated and a rather niche use case.
Perhaps we should just document the new API rather than bothering to
update the existing API call documentation, since almost certainly no
one using those APIs would ever need to think about this API?
Rich.
> ---
> generator/API.ml | 98 +++--
> generator/states-newstyle-opt-starttls.c | 40 --
> generator/states-newstyle.c | 3 +
> lib/opt.c| 50 +++
> tests/Makefile.am| 5 +
> tests/opt-starttls.c | 166 +++
> .gitignore | 1 +
> 7 files changed, 343 insertions(+), 20 deletions(-)
> create mode 100644 tests/opt-starttls.c
>
> diff --git a/generator/API.ml b/generator/API.ml
> index 69849102..8301ec9f 100644
> --- a/generator/API.ml
> +++ b/generator/API.ml
> @@ -599,7 +599,11 @@ "set_tls", {
> =item C
>
> Disable TLS. (The default setting, unless using L with
> -a URI that requires TLS)
> +a URI that requires TLS).
> +
> +This setting is also useful during integration testing when using
> +L and L for manual
> +control over when to request TLS negotiation.
>
> =item C
>
> @@ -632,7 +636,8 @@ "set_tls", {
> test whether this is the case with L.";
> example = Some "examples/encryption.c";
> see_also = [SectionLink "ENCRYPTION AND AUTHENTICATION";
> -Link "get_tls"; Link "get_tls_negotiated"];
> +Link "get_tls"; Link "get_tls_negotiated";
> +Link "opt_starttls"];
>};
>
>"get_tls", {
> @@ -657,7 +662,7 @@ "get_tls_negotiated", {
> After connecting you may call this to find out if the
> connection is using TLS.
>
> -This is only really useful if you set the TLS request mode
> +This is normally useful only if you set the TLS request mode
> to C (see L), because in this
> mode we try to use TLS but fall back to unencrypted if it was
> not available. This function will tell you if TLS was
> @@ -665,8 +670,14 @@ "get_tls_negotiated", {
>
> In C mode (the most secure) the connection
> would have failed if TLS could not be negotiated, and in
> -C mode TLS is not tried.";
> -see_also = [Link "set_tls"; Link "get_tls"];
> +C mode TLS is not tried automatically.
> +
> +However, when doing manual integration testing of server
> +behavior, when you use L along with TLS
> +request mode C before triggering the TLS
> +handshake with L, then this will report
> +the result of that manual effort.";
> +see_also = [Link "set_tls"; Link "get_tls"; Link "opt_starttls"];
>};
>
>"set_tls_certificates", {
> @@ -1092,11 +1103,12 @@ "set_opt_mode", {
> newstyle server. This setting has no effect when connecting to an
> oldstyle server.
>
> -Note that libnbd defaults to attempting
> +Note that libnbd defaults to attempting C and
> C before letting you control remaining
> -negotiation steps; if you need control over this step as well,
> -first set L to false before
> -starting the connection attempt.
> +negotiation steps; if you need control over these steps as well,
> +first set L to C and
> +L to false before starting
> +the connection attempt.
>
> When option mode is enabled, you have fine-grained control over which
> options are negotiated, compared to the default of the server
> @@ -1110,9 +1122,9 @@ "set_opt_mode", {
> see_also = [Link "get_opt_mode"; Link "aio_is_negotiating";
> Link "opt_abort"; Link "opt_go"; Link "opt_list";
> Link "opt_info"; Link "opt_list_meta_context";
> -Link "opt_set_meta_context";
> +Link "opt_set_meta_context"; Link "opt_starttls";
> Link "opt_structured_reply";
> -Link "set_request_structured_replies";
> +Link "set_tls"; Link "set_request_structured_replies";
> Link "aio_connect"];
>};
>
> @@ -1166,6 +1178,44 @@ "opt_abort", {
> see_also = [Link "set_opt_mode"; Link "aio_opt_abort"; Link "opt_go"];
>};
>
> + "opt_starttls", {
> +default_call with
> +args = []; ret = RBool;
> +permitted_states = [
Re: [Libguestfs] Parameter 'encrypt.key-secret' is required for cipher for virt-ls
On 10/05/22 16:06, Do Re wrote: > Hello all, > > background: One of my VM stopped working - on startup, I get the message > "No bootable device" in the virtual machine. > > I would like to inspect the corresponding image with libguestfs-tools. > > However, I don't know how to pass the encryption key to the tool. For > example: > > virt-ls -a /opt/vm_witherror/machine1.qcow2 / > libguestfs: trace: set_verbose true > libguestfs: trace: set_verbose = 0 > libguestfs: create: flags = 0, handle = 0x5645c40d6b00, program = virt-ls > libguestfs: trace: add_drive "/opt/vm_witherror/machine1.qcow2" > "readonly:true" > libguestfs: creating COW overlay to protect original drive content > libguestfs: trace: get_tmpdir > libguestfs: trace: get_tmpdir = "/tmp" > libguestfs: trace: disk_create "/tmp/libguestfsxECmri/overlay1.qcow2" > "qcow2" -1 "backingfile:/opt/vm_witherror/machine1.qcow2" > libguestfs: command: run: qemu-img > libguestfs: command: run: \ create > libguestfs: command: run: \ -f qcow2 > libguestfs: command: run: \ -o backing_file=/opt/vm_witherror/machine1.qcow2 > libguestfs: command: run: \ /tmp/libguestfsxECmri/overlay1.qcow2 > qemu-img: /tmp/libguestfsxECmri/overlay1.qcow2: Parameter > 'encrypt.key-secret' is required for cipher > Could not open backing image. > libguestfs: error: qemu-img: /tmp/libguestfsxECmri/overlay1.qcow2: > qemu-img exited with error status 1, see debug messages above > libguestfs: trace: disk_create = -1 (error) > libguestfs: trace: add_drive = -1 (error) > libguestfs: trace: close > libguestfs: closing guestfs handle 0x5645c40d6b00 (state 0) > libguestfs: command: run: rm > libguestfs: command: run: \ -rf /tmp/libguestfsxECmri > > > Could you please provide an example on how to get such an encrypted disk > mounted? My understanding is that libguestfs (and guestfs-tools) do not currently support the kind of encrypted disk where the encryption is implemented by QEMU, at the qcow2 layer. The kind of encryption that's expected to work is where you use LUKS internally to the guest; in other words, where disk encryption is handled by the guest kernel, rather than by QEMU. Laszlo ___ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
