@nick.lloyd As mentionned by Olivier the documentation has a mail to contact us, which will create a ticket internally, unrelated to support, that will reach the security team directly.
XAPI Wizard
Posts
-
RE: Security Assessments and Hardening of XCP-ng
-
RE: Security Assessments and Hardening of XCP-ng
The question that I'm asking here is how does the Vates Team evaluate these vulnerabilities, Qualys, Greenbone, something else?
I'm not sure what you mean by evaluate vulnerability, especially the list about Qualys, Greenboneā¦
If you mean how do we track and process them, I cannot talk about XO side, but I can shed some light on XCP-ng side:
- we have an internal dependency-track (DT) with various projects (8.2 default install, 8.2 available packages, same split for 8.3), with a custom SBOM generation, to feed DT
- this is based on CVEs and their Common Platform Enumeration (CPE)
- the main issue here is that not all CVEs fill the CPEs the same way, so there may be some misses
- we're trying to improve the SBOM generation to minimize this
- we also monitor the oss-security mailing list, and some other sources
- DT reports the CVEs that matched, and we can keep them in or mark them internally as not impacted, fixed, etc
- we evaluate the priority for us based on their general criticality, but modulate this depending on if it is in base install or not, if it is a part of the software that is meant to be used as a server, if it related to remote acces, and more
- the one we're impacted by and feel are important, we either update to the latest package version, but now that CentOS 7 is end of life, that's less likely to happen, or try to backport the fix ourselves when possible.
That's for the dom0 side, on the hypervisor side, we're part of the security list of the Xen Project, so we receive the XSAs and integrate them as fast as we can in following our release process, sometime integrating the patches ourselves, sometime going with the XenServer fixes. If we integrate them ourselves we most of the time remove our own integration and move to the one from XenServer as the people working on these fixes are mostly the ones working on the XSAs in the first place so they have a better knowledge and insigts than us.
I hope this answers this question.
Is the Vates team open to the community reporting these vulnerabilities openly or would a ticket be best?
On XCP-ng side, everything that are packages from open source would be reports of publicly disclosed CVEs, so you can openly report them. If people were to find new vulnerabilities it would depend, but should follow a classic private disclosure in the first place:
- if it's in an open source package, the upstream would be the best place to do so
- On the same idea if it's regarding Xen, XAPI, or other Xen Project software, reporting them upstream through the security process is the best way, and it could be nice to drop us a ticket for a heads up too, but that's not mandatory
- if it is for some of the packages directly coming from us, creating a ticket for us to be able to work on it before a public disclosure would be best.
Sorry, you asked about the whole ecosystem, but I'm only able to answer from the XCP-ng side of things.
- we have an internal dependency-track (DT) with various projects (8.2 default install, 8.2 available packages, same split for 8.3), with a custom SBOM generation, to feed DT
-
RE: CBT: the thread to centralize your feedback
@olivierlambert I don't think the first was ever meant to support that. Without knowing how much effort it will be, I'm leaning towards the second option, to not reset the CBT.
-
RE: CBT: the thread to centralize your feedback
@olivierlambert
xe vm-migrate
usesmigrate_send
when storage or network needs to be changed, otherwisevm.pool_migrate
is used. Selecting a new network is done through a thevif
parameter. This parameter is a map in the form ofvif:<VIF_UUID>=<NEW_NETWORK_UUID> vif:<VIF_UUID2>=<NEW_NETWORK_UUID2>
(and so on).So I'm not so sure that a netwrok migration can happen when using
pool_migrate
. -
RE: Stunnel - Future plans to use something else?
@nikade We've already fixed some issues to start using ocaml 5 regarding the C interfaces. Handling threading in ocaml 5 is still an open problem that the ecosystem has not yet solved (there are many libraries competing now). We still need to create a credible strategy to port xapi to the new model, and don't have any timelines yet