On Wed, May 3, 2023, at 10:38 PM, Dave Dykstra via epel-devel wrote:
On Wed, May 03, 2023 at 02:48:05PM -0500, Carl George wrote:> On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel> <epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:> >> > We believe that it is important to apply this change to all EPEL releases,> > for these reasons:> > 1. The general vulnerability described in this CVE applies equally to all> > currently supported Linux distributions. The Singularity/Apptainer>> CVE-2023-30549 only applies to apptainer on RHEL 7 because the> underlying vulnerability (CVE-2022-1184) has been fixed on RHEL 8 and> 9.CVE-2023-30549 most urgently applies to RHEL 7 because of the exampleof CVE-2022-1184, but as I explain in the rest of the point, it alsoapplies in general to any similar moderate or low severity memory-corruption ext4 vulnerability that will come in the future on RHEL 8 &RHEL 9 because Red Hat has no motivation to fix them urgently.
As in the other part of this thread, you are effectively arguing that the impact metrics of CVE-2022-1184 were incorrectly scored. You are additionally arguing that in future the impact metrics of filesystem CVEs are going to be scored incorrectly, such that privilege escalation vulnerabilities are scored as denial of service, hence have low / moderate severity, and are therefore not patched in a timely manner.
This is not something that can be fixed by an Apptainer CVE and incompatible change. If underlying filesystem CVEs are privilege escalations, but scored as denial of service... then that must be addressed for the benefit of everyone, not just Apptainer users.
There is a valid defence-in-depth strategy here, disabling kernel extfs mounts via apptainer-suid, that might be appropriate for a subset of users. It may or may not be appropriate as an EPEL incompatible change. But that's defence-in-depth in Apptainer, against a filesystem CVE... not a fix for an Apptainer CVE.
> > community has long been aware that making setuid-root kernel> > filesystem mounts available to all users has been a risk, because> > https://lwn.net/Articles/652468/ briefly explained that kernel> > developers considered that to be a great risk. System admins have> > been willing to live with the risk because (a) nobody had identified> > an attack, (b) the functionality was so useful, especially the> > squashfs mounts, and (c) there wasn't an alternative. With the new> > information from the ext4 kernel filesystem owner, we now have more> > specifics on how the attack can be done including an example> > vulnerability, the ext3 mounts aren't as widely used as squashfs,> > and Apptainer has an alternative using unprivileged user namespaces.> > 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default,> > so the functionality will still be available to most of the users.> > It does not automatically switch to the alternative, but there's a> > clear error message saying that it is disabled by configuration and> > suggesting that users add the --userns option (and of course if> > apptainer-suid is not installed it uses the user namespace mode> > automatically).> > 3. It is important to have consistency across platforms, since users and> > administrators often use more than one and it would be confusing to> > have different behavior on different platforms. Admins can also>> If consistency across platforms is important, then it seems prudent to> avoid this incompatible update across all three platforms, especially> this late in the RHEL 7 lifecycle.It's not prudent to leave RHEL 7 exposed to high-severity vulnerabilities.Apptainer also supports more platforms than Red Hat.
RHEL 7 users are exposed to CVE-2022-1184, which is exploitable using Apptainer. Again, CVE-2022-1184 has not been scored high-severity. If you think it is a privilege escalation that should be addressed by arguing that there is a privilege escalation vuln in extfs... which would have high impact, and should be fixed in RHEL 7. Not by inferring an incompatible change to apptainer will wave that away.
DT
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
