Can I ditch PVEPROXY? I guess not...

[Deleted member 205422]

I was wondering if I can have the 8006 port GUI wiped from most of my nodes, so netstat said it's actually pveproxy listening there.

Then documentation says it is one component also for API: https://pve.proxmox.com/pve-docs/pveproxy.8.html

From the configuration options I do not seem to be able to identify a specific component solely for the HTML frontend, does it mean I have to be stuck with web proxy listening on 8006 or completely use the API, i.e. unable to do anything with clusters? Is that it? All or nothing?

(Please do not ask me back why I want it off.)

 

[Deleted member 205422]

Embarassing, so I just confirmed if one ditches systemctl stop pveproxy on a particular node, that on the other nodes you can't see nothing in the GUI related to that node, but you can SSH in (and turn it back on).

This is new to me, having a GUI forced on each node in a cluster listening on the same port as the API.

 

[dcsapak]

as you correctly wrote, the api listens on port 8006, and the gui is simply a javascript single page application, it uses the api itself.
what exactly is the reason why you want to disable the gui? everything the gui can do is also possible via the api

 

[Deleted member 205422]

as you correctly wrote, the api listens on port 8006, and the gui is simply a javascript single page application, it uses the api itself.
what exactly is the reason why you want to disable the gui? everything the gui can do is also possible via the api

Thank you, Dominik. I understand it's not going to be hogging down the node with the SPA and it uses the very same API on the same port which the proxy serves, but suppose you only want to use some nodes to manage the cluster (as a human), it would feel better if that can be turned off. In that sense it would be really much nicer if the SPA was served by a separate tiny service on separate (configurable) port. Imagine putting a reverse proxy in front of it and that goes banana, I really would feel much better it's only hitting the SPA serving service, not the pveproxy where the whole API is.

I understand there might be different opinion on this at Proxmox, but I was surprised it's not configurable.

(NB I was exploring the same with e.g. postfix, if I can replace it safely with e.g. nullmailer, or something else entirely in fact...)

 

[Deleted member 205422]

Ok, I guess that's a "will not implement"

 

[dcsapak]

not really, but i still don't see the point in turning it off. if you don't use it, it does not use any resources and the way it's designed does not open any weak points (since all goes through the api anyway).
also because of CORS, you cannot easily put the app on a different origin (domain+scheme+port) than where you want to make api calls.

 

[Deleted member 205422]

if you don't use it, it does not use any resources

Agree, unless some undesirable traffic starts hitting it.

and the way it's designed does not open any weak points (since all goes through the api anyway).

Well it is, after all, just code, Perl has had CVEs too. At a brief glance, one codebase serves both auth and non-auth paths, but even if not, for instance, why should millions of GETs for /favicon.ico be hitting the service on a host with a hypervisor?

also because of CORS, you cannot easily put the app on a different origin (domain+scheme+port) than where you want to make api calls.

I would kind of prefer to use it this way, actually.

Somehow I got the feeling this started as a single control pane single node project, but then extended and prefers usability, just I find the configuration in this rather inflexible. I wonder if there was ever any feature request for the same, somehow I don't think I am alone.

 

[bbgeek17]

Your concern has a very easy solution - firewall the port to only allow traffic from fellow cluster members. Allow more IPs on the node you plan to use for management. Of course, if that node is ever down you would need to change the firewall rules.
If you expect malicious traffic on your network - firewall should be your best friend.

The current implementation is deeply embedded into PVE core functionality.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[dcsapak]

Agree, unless some undesirable traffic starts hitting it.

that holds true for the api too though

Well it is, after all, just code, Perl has had CVEs too. At a brief glance, one codebase serves both auth and non-auth paths, but even if not, for instance, why should millions of GETs for /favicon.ico be hitting the service on a host with a hypervisor?

again, the gui only accesses the api, so if the api is exposed, it would not matter if the gui is

i'm still not clear what you want to achieve with shutting down the gui?
what is the actual problem having the gui accessible?

as @bbgeek17 wrote, for security, use the firewall to restrict the traffic but separating control of the gui from the api does not make any sense to me

Somehow I got the feeling this started as a single control pane single node project, but then extended and prefers usability, just I find the configuration in this rather inflexible. I wonder if there was ever any feature request for the same, somehow I don't think I am alone.

on the contrary, AFAIK having the gui exposed on every node together with the api was a conscious decision because it has some advantages, e.g. not having to worry if the 'gui' node is online. you can just connect to any online node to manage
the whole cluster (some people do put a ha proxy or similar in front, so they have a single domain/ip to contact, but that introduces complexity and an extra SPOF (if not setup redundant))

 

[Deleted member 205422]

Your concern has a very easy solution - firewall the port to only allow traffic from fellow cluster members. Allow more IPs on the node you plan to use for management.

For certain threat models.

If you expect malicious traffic on your network - firewall should be your best friend.

We expect malicious traffic from all sides of the firewall, all of the time.

The current implementation is deeply embedded into PVE core functionality.

Sorry, are you guys contributors? The PVE::Service:pveproxy is already half-way there with refactoring.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

(Shouldn't partners have clearly designated accounts on a forum?)

 

[Deleted member 205422]

Ok, so this is why I originally wished not to be asked back why I want it off. No way back, so ...

i'm still not clear what you want to achieve with shutting down the gui?
what is the actual problem having the gui accessible?

It's the access control architecture, because ...

separating control of the gui from the api does not make any sense to me

... your model assumes having access to the served JS is no different than having access to the API itself, which one has to have to be able to manage the cluster. I would want to have the API put behind an extra gateway, the API of the individual nodes will be never hit directly from anywhere but the gateway. If you wonder why, because maybe I do not want anyone to be even able to POST /api2/json/access/domains/{realm}/sync and such at will.

What serves out the JS GUI (or parts of it, or something completely different) is beyond the scope of my question here, we would take care of that, including things like SPOF, etc. I did not really want to ask PVE team to redo the solution, just let me use it partially.

As you must be now scratching your head yet again (i.e. then what is it of my concern what it is there to be served out by the pveproxy.service), it's about keeping it modular and simple. It's very much like why is the 8006 port hardcoded in the Perl module, meanwhile LISTENIP can be configured, etc., etc.

As I started playing around with the IAM, I noticed it was built without eg possibility to restrict only certain network interfaces to a particular user and other similar pitfalls (for my potential use case). I did not want to go at lengths here, it's really beyond scope and it was meant to be simple question is there any plan to refactor the REST API off the HTTP server. There are simply some branches of the code in the modules I would be happier to know it is not ever executed, they are there to cater for the JS app, not pure API calls.

having the gui exposed on every node together with the api was a conscious decision

Fair enough, I did not know PVE had clustering that early on.

it has some advantages, e.g. not having to worry if the 'gui' node is online. you can just connect to any online node to manage
the whole cluster (some people do put a ha proxy or similar in front, so they have a single domain/ip to contact, but that introduces complexity and an extra SPOF (if not setup redundant))

Yes, all true, just see above within my context. I know you can tell me "you are using it wrong", but this is why I just wanted to ask if it can be a bit more modular, a little refactoring usually does not kill anyone.

Thanks for the attention anyways.

 

[dcsapak]

sorry

.. your model assumes having access to the served JS is no different than having access to the API itself, which one has to have to be able to manage the cluster. I would want to have the API put behind an extra gateway, the API of the individual nodes will be never hit directly from anywhere but the gateway. If you wonder why, because maybe I do not want anyone to be even able to POST /api2/json/access/domains/{realm}/sync and such at will.

because it is no different, that's how the SPA works. the browser downloads the js and executes the api calls. not being able to download the js/html parts wouldn't disable any functionality of the api in any way, and would not prevent anybody from calling a specific api call. If we wanted to have a gui that does not go through the api, we'd basically have to duplicate the whole api code, just for the gui (which either has then the same issues as the api, or it diverges and becomes much harder to maitnain)

basically what i want to say is, the users having access to the gui will always have (direct or indirect) access to the api, so separating them does not bring any security improvements. if you want to restrict access you can restrict both the gui and api by using the firewall

 

[Deleted member 205422]

sorry

No worries.

because it is no different, that's how the SPA works. the browser downloads the js and executes the api calls. not being able to download the js/html parts wouldn't disable any functionality of the api in any way, and would not prevent anybody from calling a specific api call.

Yes, that's why i would put in the gateway in place (or anyone who wants to, who does not can use the default current setup which will remain the same).

If we wanted to have a gui that does not go through the api, we'd basically have to duplicate the whole api code, just for the gui (which either has then the same issues as the api, or it diverges and becomes much harder to maitnain)

Here i would disagree on the consequences (I understand you want to keep it working as it is, my question was if it can be implemented in a split way), and I was not asking for duplicated codebase, just refactored, so that the parts now that have to do if this path then that and if that path then this or as this (file upload) might come from JS so let's disable CSFR check, or LDAP refresh must possible unauthenticated, etc, etc ... that all would be in the "GUI proxy endpoint" meanwhile the pure API would only allow everything authenticated. The JS would be hitting the GUI over-the-top-proxy (the code you already have, it would just be taken out of the current pveproxy.service) and that would be further served by the vanilla REST API (which you already have). For those who do not want it and only for those, they can turn off the GUI proxy entirely or on some nodes or up to them (out of scope of this thread). It would have no impact on the clean REST API.

basically what i want to say is, the users having access to the gui will always have (direct or indirect) access to the api, so separating them does not bring any security improvements. if you want to restrict access you can restrict both the gui and api by using the firewall

Yes, in default install. I basically wanted vanilla API and be able to turn off the extra GUI related clutter.

 

[Deleted member 205422]

BTW Case in point, thought there's more spots like this, even with nice commentary:

    if ($method eq 'POST' && $rel_uri =~ m|^/nodes/([^/]+)/storage/([^/]+)/upload$|) {
        my ($node, $storeid) = ($1, $2);
        # CSRF check are omitted if $isUpload is set, so check user upload permission here
        my $perm = { check => ['perm', "/storage/$storeid", ['Datastore.AllocateTemplate']] };
        $rpcenv->check_api2_permissions($perm, $username, {});
        $isUpload = 1;
    }

    # Skip CSRF check for file upload (difficult to pass CSRF header with native html forms).
    # Also skip the check with API tokens, as one of the design goals of API tokens was to
    # provide stateless API access without requiring round-trips to get such CSRF tokens.
    # CSRF-prevention also does not make much sense outside of the browser context.
    if ($method ne 'GET' && !($api_token || $isUpload)) {
        my $euid = $>;
        PVE::AccessControl::verify_csrf_prevention_token($username, $token) if $euid != 0;
    }

https://github.com/proxmox/pve-mana...5a6a97e99deeb0ef2e8d2e/PVE/HTTPServer.pm#L109

 

[dcsapak]

these things would have to be in the api even if the gui was separated, since otherwise we then couldn't upload via the gui. the only possible way would be to duplicate the code (as i already wrote) which leads to hard to maintain code and possibly to even more security issues, since the code paths could diverge. (e.g. if the gui proxy endpoint would generate the csrf for the gui, it would not increase security for that? or if the realm list has to be accessible in the gui unauthenticated, the api must expose that too? else how would the gui proxy that info?)

if you want to prevent such things, you can still setup a reverse proxy before your pve and filter out the api calls you don't want to have, but we will (nearly) always design the api in a way that is usable from the gui, since that's our main client

 

[Deleted member 205422]

these things would have to be in the api even if the gui was separated,

Yes, no issue.

the only possible way would be to duplicate the code

Perl does have the use base directive, so I don’t understand this rationale to be honest even after looking at the modules, it looks fine to me to refactor without bloating codebase, if anything would be easier to read / audit.

(e.g. if the gui proxy endpoint would generate the csrf for the gui, it would not increase security for that

Correct, for default install. It would increase it for those that decide to turn that extra component off.

? or if the realm list has to be accessible in the gui unauthenticated, the api must expose that too

Yes but same as above and I could lock down parts of REST API by paths.

if you want to prevent such things, you can still setup a reverse proxy before your pve and filter out the api calls you don't want to have

It would still be running the same extra branched code which is changing every time in the future when there’s a need to care for GUI JS features

but we will (nearly) always design the api in a way that is usable from the gui, since that's our main client

I know that.

 

[dcsapak]

In my opinion the issues you want to avoid does not warrant the effort we'd have to take to avoid them in the way you describe (and it does not even guarantee that it avoids them)
e.g, having seperate gui paths, even if you reuse a big chunk of the code, will very likely lead to bugs because of the difference in handling, for instance if some dev isn't aware of the "other" codepath or simply forgot it exists)

i'd rather fix those critical code paths so that there is no need at all for them (if that's possible)
would you mind opening a bug/feature request (https://bugzilla.proxmox.com) for the missing csrf check for uploads? we might not be able to fix it in a simple way but having a bug for it allows us to track it better and maybe someone has an idea how to improve that

the public list of realm i fear won't go away, and I'm very sure we won't split the gui out in a way you have imagined

if you find any other issues with the api, please too open a bug on our bugtracker.

thanks

 

[Deleted member 205422]

In my opinion the issues you want to avoid does not warrant the effort we'd have to take to avoid them

Noted.

i'd rather fix those critical code paths so that there is no need at all for them (if that's possible)
would you mind opening a bug/feature request (https://bugzilla.proxmox.com) for the missing csrf check for uploads? we might not be able to fix it in a simple way but having a bug for it allows us to track it better and maybe someone has an idea how to improve that

I certainly might do that, but I actually do not see any clean way to "fix" it than by refactoring it, which is why I asked the way I did - the quoted code above with comment on CSRF for uploads basically sums it all up for me. As long as there is one endpoint for both vanilla API calls and browser traffic on the other end, the proxy will have to remain - in my opinion - convoluted. In that sense the current code is not a bug. I would not call it a feature (or anti-feature), it's a product of the architectural decision.

the public list of realm i fear won't go away, and I'm very sure we won't split the gui out in a way you have imagined

See above.

if you find any other issues with the api, please too open a bug on our bugtracker.

That I would do.

thanks

Appreciate the honest interaction.

 

[Deleted member 205422]

Btw I have just submitted an update on what I believe is another issue as a comment to https://bugzilla.proxmox.com/show_bug.cgi?id=4886

Then noticed it does not seem assigned to anyone, status is undecided and there was some last discussion only in August. I do not think the bug is minor, it seems to affect everyone who ever rejoined a new node under same name/IP as an old (dead/removed) one. Is it looked on by someone to be decided as assigned/severity level/etc?

 

[dcsapak]

not sure, not too familiar with the bug, but if you wrote an new answer with new information, we usually respond (but maybe not instantly )