9:35 a.m.
For fuller explanation see:
https://bugzilla.redhat.com/show_bug.cgi?id=2066773#c1
I'm not very happy with this patch for a few reasons:
- Does every distro use "qemu" as the user that runs qemu?
- Having to run an external process (not a big deal, but a bit clumsy)
- Aren't ACLs actually deprecated?
Anyway the patch does at least work in my local testing.
Rich.
9:35 a.m.
When using the libvirt backend and running as root, libvirt will run
qemu as a non-root user (eg. qemu:qemu). The v2v directory stores NBD
endpoints that qemu must be able to open and so we set the directory
to mode 0711. Unfortunately this permits any non-root user to open
the sockets (since, by design, they have predictable names within the
directory).
So instead of using directory permissions, use an ACL which allows us
to precisely give access to the qemu user and no one else.
Reported-by: Xiaodai Wang
Thanks: Dr David Gilbert
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2066773
---
lib/utils.ml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/utils.ml b/lib/utils.ml
index 757bc73c8e..5623250832 100644
--- a/lib/utils.ml
+++ b/lib/utils.ml
@@ -158,8 +158,12 @@ let error_if_no_ssh_agent () =
(* Create the directory containing inX and outX sockets. *)
let create_v2v_directory () =
let d = Mkdtemp.temp_dir "v2v." in
+ (* If running as root, and if the backend is libvirt, libvirt
+ * will run qemu as a non-root user. Allow qemu to open the directory.
+ *)
let running_as_root = Unix.geteuid () = 0 in
- if running_as_root then Unix.chmod d 0o711;
+ if running_as_root && backend_is_libvirt () then
+ ignore (Sys.command (sprintf "setfacl -m user:qemu:rwx %s" (quote d)));
On_exit.rmdir d;
d
--
2.35.1
11:10 a.m.
On 03/22/22 15:35, Richard W.M. Jones wrote:
When using the libvirt backend and running as root, libvirt will run
qemu as a non-root user (eg. qemu:qemu). The v2v directory stores NBD
endpoints that qemu must be able to open and so we set the directory
to mode 0711. Unfortunately this permits any non-root user to open
the sockets (since, by design, they have predictable names within the
directory).
Are the NBD socket pathnames visible on the QEMU command line ("ps -ef"
or "ps auxwww")?
If not, then the issue could be prevented by inserting a directory with
a hard-to-guess name in the middle (e.g. one named by uuidgen).
So instead of using directory permissions, use an ACL which allows us
to precisely give access to the qemu user and no one else.
If we may assume the "qemu" user name (and we're root), we can just give
qemu:root ownership to the directory, and file mode bits 0700. The qemu
user will have access, and v2v (running as root) will not be hindered by
a theoretical lack of access rights.
Reported-by: Xiaodai Wang
Thanks: Dr David Gilbert
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2066773
---
lib/utils.ml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/utils.ml b/lib/utils.ml
index 757bc73c8e..5623250832 100644
--- a/lib/utils.ml
+++ b/lib/utils.ml
@@ -158,8 +158,12 @@ let error_if_no_ssh_agent () =
(* Create the directory containing inX and outX sockets. *)
let create_v2v_directory () =
let d = Mkdtemp.temp_dir "v2v." in
+ (* If running as root, and if the backend is libvirt, libvirt
+ * will run qemu as a non-root user. Allow qemu to open the directory.
+ *)
let running_as_root = Unix.geteuid () = 0 in
- if running_as_root then Unix.chmod d 0o711;
+ if running_as_root && backend_is_libvirt () then
+ ignore (Sys.command (sprintf "setfacl -m user:qemu:rwx %s" (quote d)));
On_exit.rmdir d;
d
Not ideal -- yet another facility, in order to get around a security
measure we put in place ourselves -- but it gets the job done...
Acked-by: Laszlo Ersek <lersek(a)redhat.com>
12:42 p.m.
On Tue, Mar 22, 2022 at 05:10:07PM +0100, Laszlo Ersek wrote:
On 03/22/22 15:35, Richard W.M. Jones wrote:
> When using the libvirt backend and running as root, libvirt will run
> qemu as a non-root user (eg. qemu:qemu). The v2v directory stores NBD
> endpoints that qemu must be able to open and so we set the directory
> to mode 0711. Unfortunately this permits any non-root user to open
> the sockets (since, by design, they have predictable names within the
> directory).
Are the NBD socket pathnames visible on the QEMU command line ("ps -ef"
or "ps auxwww")?
If not, then the issue could be prevented by inserting a directory with
a hard-to-guess name in the middle (e.g. one named by uuidgen).
Unfortunately yes they're visible in "ps", and anyway we want these to
be well-known paths (for the _same_ user!)
> So instead of using directory permissions, use an ACL which
allows us
> to precisely give access to the qemu user and no one else.
If we may assume the "qemu" user name (and we're root), we can just give
qemu:root ownership to the directory, and file mode bits 0700. The qemu
user will have access, and v2v (running as root) will not be hindered by
a theoretical lack of access rights.
This might not be a bad idea actually. Root ignores permissions
usually as you say.
> Reported-by: Xiaodai Wang
> Thanks: Dr David Gilbert
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2066773
> ---
> lib/utils.ml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/lib/utils.ml b/lib/utils.ml
> index 757bc73c8e..5623250832 100644
> --- a/lib/utils.ml
> +++ b/lib/utils.ml
> @@ -158,8 +158,12 @@ let error_if_no_ssh_agent () =
> (* Create the directory containing inX and outX sockets. *)
> let create_v2v_directory () =
> let d = Mkdtemp.temp_dir "v2v." in
> + (* If running as root, and if the backend is libvirt, libvirt
> + * will run qemu as a non-root user. Allow qemu to open the directory.
> + *)
> let running_as_root = Unix.geteuid () = 0 in
> - if running_as_root then Unix.chmod d 0o711;
> + if running_as_root && backend_is_libvirt () then
> + ignore (Sys.command (sprintf "setfacl -m user:qemu:rwx %s" (quote
d)));
> On_exit.rmdir d;
> d
>
>
Not ideal -- yet another facility, in order to get around a security
measure we put in place ourselves -- but it gets the job done...
Yup, I'm not especially happy with either solution. I might play
around with your idea above of setting permissions to qemu:root.
Acked-by: Laszlo Ersek <lersek(a)redhat.com>
Thanks,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
9:51 a.m.
On Tue, Mar 22, 2022 at 02:35:54PM +0000, Richard W.M. Jones wrote:
For fuller explanation see:
https://bugzilla.redhat.com/show_bug.cgi?id=2066773#c1
I'm not very happy with this patch for a few reasons:
- Does every distro use "qemu" as the user that runs qemu?
Not sure, but you can query this from libvirt
# virsh capabilities | xmllint -xpath
'//secmodel[./model="dac"]/baselabel[@type="kvm"]' -
<baselabel type="kvm">+107:+107</baselabel>
The base level here is the label that any files must have in order
to be writable by QEMU, using a default process label.
In the case of the 'dac' model this is a UID:GID pair (+ indicates
numeric ID, as opposed to a username with all numbers).
NB, this doesn't apply if you're overriding the default label to
use a distinct UID per VM, but I assume v2v isn't doing that and
controls its own VMs
- Having to run an external process (not a big deal, but a bit
clumsy)
In theory libacl gives you programmatic API for this.
- Aren't ACLs actually deprecated?
Not that I know of.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
11:14 a.m.
On 03/22/22 15:51, Daniel P. Berrangé wrote:
On Tue, Mar 22, 2022 at 02:35:54PM +0000, Richard W.M. Jones wrote:
> For fuller explanation see:
> https://bugzilla.redhat.com/show_bug.cgi?id=2066773#c1
>
> I'm not very happy with this patch for a few reasons:
>
> - Does every distro use "qemu" as the user that runs qemu?
Not sure, but you can query this from libvirt
# virsh capabilities | xmllint -xpath
'//secmodel[./model="dac"]/baselabel[@type="kvm"]' -
<baselabel type="kvm">+107:+107</baselabel>
There is XML support in OCaml, and I guess we can figure out if we use
TCG vs. KVM, so the "xmllint" command could be written in v2v.
I'm not sure about "virsh capabilities" :/ Would we need to wrap
virConnectGetCapabilities() <https://libvirt.org/formatcaps.html>?
Thanks,
Laszlo
The base level here is the label that any files must have in order
to be writable by QEMU, using a default process label.
In the case of the 'dac' model this is a UID:GID pair (+ indicates
numeric ID, as opposed to a username with all numbers).
NB, this doesn't apply if you're overriding the default label to
use a distinct UID per VM, but I assume v2v isn't doing that and
controls its own VMs
> - Having to run an external process (not a big deal, but a bit clumsy)
In theory libacl gives you programmatic API for this.
> - Aren't ACLs actually deprecated?
Not that I know of.
With regards,
Daniel
979
days inactive
979
days old
5 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Laszlo Ersek -
Richard W.M. Jones