Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

>     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.

>     install the rpm on RHEL8 & 9 directly from github, and it would not
>     be good to have different behavior when installed from EPEL.
>
> Dave
>
>
> On Thu, Apr 27, 2023 at 02:42:13AM -0500, Carl George wrote:
> ...
> > EPEL 9:
> >
> > RHEL 9 has the fix for CVE-2022-1184.  CVE-2023-30549 requires
> > CVE-2022-1184 to be unpatched.  Because of this I'm opposed to an
> > incompatible update for apptainer in EPEL 9.  Apptainer in EPEL 9
> > should be modified to set the "allow setuid-mount extfs" option to yes
> > for compatibility, even if that isn't the upstream default.
> >
> > EPEL 8:
> >
> > RHEL 8 has the fix for CVE-2022-1184.  CVE-2023-30549 requires
> > CVE-2022-1184 to be unpatched.  Because of this I'm opposed to an
> > incompatible update for apptainer in EPEL 8.  Apptainer in EPEL 8
> > should be modified to set the "allow setuid-mount extfs" option to yes
> > for compatibility, even if that isn't the upstream default.
> >
> > EPEL 7:
> >
> > RHEL 7 appears to be vulnerable to CVE-2022-1184.  CVE-2023-30549
> > requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it
> > actually impacts the EPEL 7 apptainer package.  This CVE has not yet
> > been rated by NVD.  If the NVD assigns a rating of high (matching the
> > CNA suggestion) or critical, I would be agreeable to an incompatible
> > update of apptainer in EPEL 7.  If the NVD assigns a rating of medium
> > (matching CVE-2022-1184) or low, I would be opposed to an incompatible
> > update of apptainer in EPEL 7.
> >
> > https://nvd.nist.gov/vuln/detail/CVE-2023-30549
> _______________________________________________
> 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



-- 
Carl George
_______________________________________________
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




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux