Re: [pve-devel] is the next pve version 8.0 with debian 12 ? (any planning on patches merge ?)

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On April 28, 2023 11:33 am, Thomas Lamprecht wrote:
> Am 28/04/2023 um 09:15 schrieb DERUMIER, Alexandre:
>> We had discussed about it last year, but I would like to implement
>> permissions on vmbrX && sdn vnets, as it a breaking change.
>> https://git.proxmox.com/?p=pve-manager.git;a=commit;h=a37ff602ff742403f01d6682bf9948183f87eadb
>> 
> 
> yes, here the questions is more if we want to map in below some more
> general resource-mapping ACL path as slightly/peripherally hinted in
> a reply[0] to Dominik's HW mapping series. Or if we want to keep netdevs
> in the /sdn path, which might be fine too as network devices is a big
> and important enough class to be kept all in their own "access category"
> 
> [0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054557.html
> 
> Fabian has some more spelled out questions/ideas IIRC.

not so much spelled out, but yeah, this came up recently again because
of a forum question :)

I would really like to have the ability to restrict access to bridges
and bridge-like entities from SDN in 8.0. right now it's only possible
to limit the configuration itself, but not the "usage". for SDN there is
a cosmetic filter in place, but that is only cosmetic, as long as a
user/token has VM.Config.Network they can use *any* bridge or *any*
vnet via the API.

these are the basic parts I've thought of:

1.) decide on the ACLs/privs for regular bridges

- ACL path and privileges shared with SDN
- OR: ACL path and privileges shared with other per-node hardware
  entities, like those used for pass-through

the former is probably more easy, since it means we don't need special
helpers or complicated code when checking access in places where either
a regular bridge or SDN is used.. the advantage of the map would be that
we'd have a single mechanism for defining and giving access to per-node
resources. so not really clear cut (yet)

- which privilege levels do we need?
- See (Audit), Use, Configure (Admin)?

2.) implement access control checks in all the places

- mostly guest-related: create/restore/update/remote-migrate/clone
- firewall (rules referencing bridges/vnets? maybe it doesn't matter,
  since if I can change the host firewall I can already mess stuff up,
  and for the guest firewall I can probably use whatever I want?)
- SDN (e.g., to configure a zone to use a certain bridge?)
- node network config (switch from Sys.Modify to SDN.Admin?)

once the decision on the privileges has been made, we need to backport
any new privileges to the last 7.x version, so that admins can setup the
new ACLs before (partially!) upgrading their clusters, and also to avoid
breaking not-yet-updated nodes when ACLs are modified on already
upgraded ones.