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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal