From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server v3 10/11] allow non-root users to set /dev/u?random as an RNG source
Date: Tue, 11 Feb 2025 13:34:50 +0100 [thread overview]
Message-ID: <1739276325.ym88x8dfon.astroid@yuna.none> (raw)
In-Reply-To: <20250210153734.103381-11-f.schauer@proxmox.com>
On February 10, 2025 4:37 pm, Filip Schauer wrote:
> Allow non-root users with the VM.Config.HWType privilege to configure
> /dev/urandom & /dev/random as an entropy source for a VirtIO RNG device.
> /dev/hwrng remains restricted to the root user.
>
> Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
> ---
> PVE/API2/Qemu.pm | 43 +++++++++++++++++++++++++++++++++++++++++++
> PVE/QemuServer.pm | 13 +++++++++++--
> 2 files changed, 54 insertions(+), 2 deletions(-)
>
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index 295260e7..194e6357 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -38,6 +38,7 @@ use PVE::QemuServer::Memory qw(get_current_memory);
> use PVE::QemuServer::MetaInfo;
> use PVE::QemuServer::PCI;
> use PVE::QemuServer::QMPHelpers;
> +use PVE::QemuServer::RNG;
> use PVE::QemuServer::USB;
> use PVE::QemuMigrate;
> use PVE::RPCEnvironment;
> @@ -673,6 +674,7 @@ my $hwtypeoptions = {
> 'vga' => 1,
> 'watchdog' => 1,
> 'audio0' => 1,
> + 'rng0' => 1,
> };
>
> my $generaloptions = {
> @@ -801,6 +803,36 @@ my sub check_vm_create_hostpci_perm {
> return 1;
> };
>
> +my sub check_rng_perm {
> + my ($rpcenv, $authuser, $vmid, $pool, $opt, $value) = @_;
> +
> + return 1 if $authuser eq 'root@pam';
> +
> + $rpcenv->check_vm_perm($authuser, $vmid, $pool, ['VM.Config.HWType']);
> +
> + my $device = PVE::JSONSchema::parse_property_string('pve-qm-rng', $value);
> + if ($device->{source}) {
> + if ($device->{source} eq '/dev/hwrng') {
> + die "only root can set '$opt' config for a non-mapped Hardware RNG device\n";
> + }
> + }
> +
> + return 1;
> +}
> +
> +my sub check_vm_create_rng_perm {
> + my ($rpcenv, $authuser, $vmid, $pool, $param) = @_;
> +
> + return 1 if $authuser eq 'root@pam';
> +
> + foreach my $opt (keys %{$param}) {
> + next if $opt !~ m/^rng\d+$/;
> + check_rng_perm($rpcenv, $authuser, $vmid, $pool, $opt, $param->{$opt});
> + }
> +
> + return 1;
> +};
there only ever is one rng device at the moment, so this could be
dropped..
> +
> my $check_vm_modify_config_perm = sub {
> my ($rpcenv, $authuser, $vmid, $pool, $key_list) = @_;
>
> @@ -1114,6 +1146,7 @@ __PACKAGE__->register_method({
> &$check_vm_create_serial_perm($rpcenv, $authuser, $vmid, $pool, $param);
> check_vm_create_usb_perm($rpcenv, $authuser, $vmid, $pool, $param);
> check_vm_create_hostpci_perm($rpcenv, $authuser, $vmid, $pool, $param);
> + check_vm_create_rng_perm($rpcenv, $authuser, $vmid, $pool, $param);
and this could instead be
check_rng_perm($rpcenv, $authuser, $vmid, $pool, 'rng0', $param->{rng0})
if $param->{rng0};
?
>
> PVE::QemuServer::check_bridge_access($rpcenv, $authuser, $param);
> &$check_cpu_model_access($rpcenv, $authuser, $param);
> @@ -2005,6 +2038,10 @@ my $update_vm_api = sub {
> check_hostpci_perm($rpcenv, $authuser, $vmid, undef, $opt, $val);
> PVE::QemuConfig->add_to_pending_delete($conf, $opt, $force);
> PVE::QemuConfig->write_config($vmid, $conf);
> + } elsif ($opt eq m/^rng\d+$/) {
> + check_rng_perm($rpcenv, $authuser, $vmid, undef, $opt, $val);
> + PVE::QemuConfig->add_to_pending_delete($conf, $opt, $force);
> + PVE::QemuConfig->write_config($vmid, $conf);
> } elsif ($opt eq 'tags') {
> assert_tag_permissions($vmid, $val, '', $rpcenv, $authuser);
> delete $conf->{$opt};
> @@ -2095,6 +2132,12 @@ my $update_vm_api = sub {
> }
> check_hostpci_perm($rpcenv, $authuser, $vmid, undef, $opt, $param->{$opt});
> $conf->{pending}->{$opt} = $param->{$opt};
> + } elsif ($opt =~ m/^rng\d+$/) {
> + if (my $oldvalue = $conf->{$opt}) {
> + check_rng_perm($rpcenv, $authuser, $vmid, undef, $opt, $oldvalue);
> + }
> + check_rng_perm($rpcenv, $authuser, $vmid, undef, $opt, $param->{$opt});
> + $conf->{pending}->{$opt} = $param->{$opt};
> } elsif ($opt eq 'tags') {
> assert_tag_permissions($vmid, $conf->{$opt}, $param->{$opt}, $rpcenv, $authuser);
> $conf->{pending}->{$opt} = PVE::GuestHelpers::get_unique_tags($param->{$opt});
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 70518924..cc69eeb1 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -6398,8 +6398,17 @@ sub check_mapping_access {
> } else {
> die "either 'host' or 'mapping' must be set.\n";
> }
> - }
> - }
> + } elsif ($opt =~ m/^rng\d+$/) {
> + my $device = PVE::JSONSchema::parse_property_string('pve-qm-rng', $conf->{$opt});
> +
> + if ($device->{source}) {
> + if ($device->{source} eq '/dev/hwrng') {
> + die "only root can set '$opt' config for a non-mapped Hardware RNG device\n"
> + if $user ne 'root@pam';
> + }
> + }
> + }
those are three nested ifs that could be a single one?
if ($device->{source} && $device->{source} eq '/dev/hwrng' && $user ne 'root@pam') {
}
I guess we could even move the root check for the whole sub up front as
a precursor patch, to simplify the if conditions a bit..
I also wonder whether it makes sense to allow /dev/urandom and
/dev/random as mappings if they are not restricted in the first place
when used directly? what's the advantage of that?
> + }
> };
>
> sub check_restore_permissions {
> --
> 2.39.5
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-02-11 12:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 15:37 [pve-devel] [PATCH cluster/guest-common/manager/qemu-server v3 00/11] fix #5657: allow configuring RNG device as non-root user Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH guest-common v3 01/11] mapping: add a hardware RNG mapping config Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH cluster v3 02/11] cfs: add 'mapping/hwrng.cfg' to observed files Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 03/11] introduce hardware rng mapping api Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 04/11] introduce hardware rng scanning api Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 05/11] ui: add hardware RNG resource mapping Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 06/11] ui: allow use of mapped hardware RNGs as entropy sources for VMs Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH manager v3 07/11] ui: split resource mapping types into tabbed views Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH qemu-server v3 08/11] refactor: move rng related code into its own module Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH qemu-server v3 09/11] add helpers for VirtIO RNG command line arguments Filip Schauer
2025-02-10 15:37 ` [pve-devel] [PATCH qemu-server v3 10/11] allow non-root users to set /dev/u?random as an RNG source Filip Schauer
2025-02-11 12:34 ` Fabian Grünbichler [this message]
2025-02-10 15:37 ` [pve-devel] [PATCH qemu-server v3 11/11] let VirtIO RNG devices source entropy from mapped HWRNGs Filip Schauer
2025-02-11 12:34 ` Fabian Grünbichler
2025-02-11 12:34 ` [pve-devel] [PATCH cluster/guest-common/manager/qemu-server v3 00/11] fix #5657: allow configuring RNG device as non-root user Fabian Grünbichler
2025-02-18 11:17 ` Filip Schauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1739276325.ym88x8dfon.astroid@yuna.none \
--to=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.