[ClusterLabs] jquery in pcs package

[Strahil Nikolov]

Firewalld's add-service (without zone definition)  will  add it on the default zone which by default is public.
If you have public  and private zones ,  and the cluster is supposed  to communicate over the private VLAN,  you can open the port only there.

Best Regards,
Strahil  Nikolov

На 2 юли 2020 г. 13:40:02 GMT+03:00, Tony Stocker <akostocker at gmail.com> написа:
>On Wed, Jul 1, 2020 at 1:44 PM Tony Stocker <akostocker at gmail.com>
>wrote:
>>
>> So, first question: is this jquery something that is maintained,
>> promulgated by/with the Pacemaker installation? Or is this something
>> special that Red Hat is doing when they package it?
>
>So, investigating the source code in GitHub, the inclusion of this
>jquery is part of Pacemaker/pcs and related to the Web UI. So this
>should be the proper forum to address it.
>
>> Second, if this is Pacemaker-maintained (not Red Hat) part of code,
>is
>> there a reason that it's such an old version, given that the current
>> version is 3.5.0, is used?
>
>Based on the GitHub check-in date, it appears that this section of
>code hasn't been updated in 7 years.
>
>> Finally, if this is Pacemaker-maintained (not Red Hat) part of code,
>> where can I find the documentation regarding the patching that's been
>> done to address the various cross-site scripting vulnerabilities? I'm
>> working under the assumption that the binary has been patched and the
>> vulnerabilities are no longer present, in which case I have to
>> document it with security. Obviously if the code has not been patched
>> and it's still vulnerable, that's a whole different issue.
>
>So, one would assume since there haven't been any updates to the code
>that this code is indeed vulnerable to all the XSS vulnerabilities,
>which is not good. Regardless of anything else below, does anyone know
>if there are any plans to update this part of the code to deal with
>these security issues?
>
>What appears to be worse is that this Web UI interface is not
>optional, and runs on the communication port (default=2224) across all
>interfaces on a system. So, even though I set up a cluster using host
>names/addresses which are on a private lan, the security scanner tool
>is still finding the Web UI running on port 2224 on the public IP
>interface of the system. This can't be the correct/intended behavior,
>can it? I'm thinking that this has to do with the setup step that I
>see in pretty much all how-to documents that looks like this one from
>the Red Hat 8 "Configuring and Maintaining High Availability Clusters"
>document, section 4.7:
>
>"If you are running the firewalld daemon, execute the following
>commands to enable the ports that are required by the Red Hat High
>Availability Add-On.
># firewall-cmd --permanent --add-service=high-availability
># firewall-cmd --add-service=high-availability"
>
>Here is the description in the same document for Port 2224/tcp:
>"Default pcsd port required on all nodes (needed by the pcsd Web UI
>and required for node-to-node communication). You can configure the
>pcsd port by means of the PCSD_PORT parameter in the
>/etc/sysconfig/pcsd file.
>
>It is crucial to open port 2224 in such a way that pcs from any node
>can talk to all nodes in the cluster, including itself. When using the
>Booth cluster ticket manager or a quorum device you must open port
>2224 on all related hosts, such as Booth arbiters or the quorum device
>host. "
>
>Executing this command appears to add the 'high-availability'
>"service" to all zones in firewalld, which I don't believe is needed,
>or am I wrong? If you have nodes with multiple network interfaces (in
>my test case each node is attached to 3 networks,) do the nodes have
>to have pcsd access across all the networks?
>
>Even if I can mitigate things by only allowing 'high-availability'
>service ports on a single, private LAN, is there any way to DISABLE
>the Web UI so that it doesn't run at all? I don't use it, nor have any
>intention of doing so, and having a separate, unmaintained (as in
>patched for vulnerabilities) http service running on a 'random' port
>is not something our project management, and certainly the security
>division approves of doing.
>
>Thanks.
>_______________________________________________
>Manage your subscription:
>https://lists.clusterlabs.org/mailman/listinfo/users
>
>ClusterLabs home: https://www.clusterlabs.org/