epel

#226 Incompatible update in apptainer-suid-1.1.8
Closed: Fixed by tdawson. Opened by dwd.

Closed: Fixed
Reopen Issue

As first discussed on epel-devel: apptainer-suid-1.1.8 by default disables mounting of ext3 filesystems, because of an announced high-severity vulnerability, CVE-2023-30549. I request permission to distribute this change in EPEL.

Most users don't use this feature, but a significant minority does. Apptainer has a non-setuid alternative for the same functionality if unprivileged user namespaces are available. System administrators that want to continue to keep the setuid-root functionality can do it by changing a configuration option.

The summary of the CVE is that the way that Apptainer & Singularity allow mounts of ext3 filesystems in setuid mode raises the severity of many ext4 filesystem CVEs (ext3 filesystems are implemented by the ext4 driver). OS vendors consider those CVEs to be low or moderate severity because they assume that users do not have write access to the underlying bits of the filesystem, but Apptainer/Singularity setuid mode gives that access to users by default (before this release of Apptainer). Since vendors don't see urgency to patch low/moderate CVEs, it can take a very long time for them to patch them and in fact RHEL7 is not patched for one in particular. All this information came from a reliable source, the owner of the ext4 kernel driver.

Metadata Update from @tdawson:
- Issue tagged with: meeting

Can you clarify if you're asking about only EL7, or also 8/9? I notice apptainer-1.1.8 in testing for EPEL8 and EPEL9 as well.

We are asking for all 3. First, we don't think it would be a good idea to make the default behavior different on different operating systems versions. In addition, all kernel versions are vulnerable to the general principle; that is, in the future when additional similar ext4 CVEs are found, they will also be considered low or moderate severity so they will be delayed to the next major point release of RHEL instead of getting the high severity treatment that apptainer-suid would expose them to.
Edited by dwd

I forgot to mention corresponding bugzillas ids: #2189897, #2189898, #2189640.

We discussed this at today's EPEL Steering Committee meeting. Since the devel list emails and this issue were opened the same day as the meeting, we agreed to postpone a vote on this until next week in order to give committee members time to review the situation before voting.

We discussed this at today's EPEL Steering Committee meeting. No committee members present voiced supported for allowing this incompatible update in EPEL 8 or 9. For EPEL 7, multiple members stated they would like to delay voting for at least a week, or possibly even until NVD issues an official score on CVE-2023-30549.

NVD has finished their CVE-2023-30549 analysis and issued a rating even higher than I had proposed, 7.8 (because they rated the attack complexity as low when I said it was high).

So I think it's clear that the change needs to go into at least EPEL7. I also feel strongly that all OS distributions should have the same default settings and that all of them should be protected by default from similar future vulnerabilities. RHEL8 & 9 also have unprivileged user namespaces available by default, so the unprivileged alternative based on fuse2fs will be available by default to users, not causing them much of an inconvenience.

Unfortunately I will not be available to attend the next meeting, but I request that approval be granted to release this so that the systems that have apptainer-suid or singularity installed will have the fix for this vulnerability made available to them without further delay.

We discussed this in the weekly EPEL Steering Committee meeting. We broke this into two separate votes.

Allow the epel 7 update : Passed
Votes: All who voted, voted in favor of this.
Notes: No notes.

Allow the epel 8 and 9 update - with a stern warning : Passed
Votes: 4 for, 2 against, 1 abstaining
Notes: Although your argument was that these needed the same breaking configurations to prevent future security issues, that wasn't what swayed the votes. The first reason was that having older versions in epel 8 and 9 causes more problems. The second reason was that we felt we didn't give you a stern enough warning last time.

WARNING / ADVISEMENT / ATTENTION
This is the second time that apptainer has had breaking updates. The EPEL Steering Committee feels that if this happens again, then apptainer isn't a good fit for EPEL. We will pull apptainer from EPEL and recommend that you release it in COPR instead of EPEL. Please inform the upstream maintainers of this.
Edited by tdawson

Metadata Update from @tdawson:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

xref: https://pagure.io/fesco/issue/2997

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/226

Please continue any further discussion there.
Metadata
None

meeting

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.