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 Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel
<epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> DT is correct, this change is subject to the EPEL incompatible change
> policy.  apptainer-suid-1.1.8 by default disables mounting of ext3
> filesystems, because of CVE-2023-30549
>     https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
> 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.
>
> 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 priority
> 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.

The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the
NVD CVSS score.  Both rate the "privileges required" property as low.
>From what I can tell that property would be rated high if they
considered root privileges to be required.  How does apptainer's use
of setuid change anything here?

>
> I am sorry to see that I have already done one step too many according
> to the incompatible changes policy, and have made the release available
> to epel-testing.  However, I think it's important to make it available
> that way for system administrators to install early.  The large High
> Energy Physics community that I represent has security teams that want
> to be able to notify their site administrators to upgrade to respond to
> this high severity CVE, and it would be so much better if the
> announcement they send can say to install from epel-testing rather than
> having to provide URLs to download from koji.

You can't just ignore the policy because you feel it's important to
make a particular update available quickly.  If you feel the policy
needs to allow for things to be done in that order, propose a change
to the policy.  I don't consider it a good idea, because if the
committee denies the update you have to do a revert commit and
possibly even add/increment an epoch to provide a correct upgrade path
to all users.  If you have a build you're not sure will be allowed in
EPEL, but you want to provide it quickly on an opt-in basis, I suggest
using copr instead.  If the update is approved you can increment the
release for the official EPEL build to have a clean upgrade path from
the copr build back to the EPEL build.

>
> So, to the EPEL Steering Committee members: must I unpublish this update
> from testing, or may I leave it there and send an announcement to
> epel-announce that it is there and pending approval by the committee?
> The bodhi settings are set so they won't get auto-updated by karma or
> time.

We discussed this earlier today at the Steering Committee meeting.  No
one seemed to have an issue with allowing these updates to stay in the
testing repo until we vote on it next week.  Next time, follow the
policy steps correctly.

>
> And another question: should I submit an epel ticket for this?  The
> policy doesn't mention that.
>
> Dave
>
> On Wed, Apr 26, 2023 at 09:41:16AM +0100, David Trudgian wrote:
> > Subject: Re: apptainer 1.1.8-1 appears to be an incompatible upgrade for apptainer-suid users
> >
> > Hello,
> >
> > The maintainer of the apptainer package has submitted updates to version 1.1.8-1 against epel-testing:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-18a0e3fa23
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-44ff2475c4
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b31211e2ce
> >
> > I believe that the update should be considered an incompatible upgrade, requiring the incompatible upgrades policy to be followed, as it significantly changes behaviour for users who have the apptainer-setuid sub-package installed.
> >
> > The update now disallows, by default, workflows that involve ext format container images and overlays:
> >
> > ```
> > # Before update
> > $ apptainer exec sif-overlay.sif /bin/date
> > Wed Apr 26 09:12:37 BST 2023
> >
> > # Update to the testing package
> > $ sudo dnf update --enablerepo=epel-testing apptainer-suid
> >
> > # After update
> > $ apptainer exec sif-overlay.sif /bin/date
> > FATAL:   configuration disallows users from mounting SIF extfs partition in setuid mode, try --userns
> > ```
> >
> > I understand that the update is related to a security issue that upstream has published:
> >
> > CVE-2023-30549  - https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
> >
> > However, I don't think this exempts the update from the incompatible upgrades policy?
> >
> > I'd also like to note that CVE-2023-30549 is dependent on and potentially a duplicate of CVE-2022-1184, which has been patched in EL8 and EL9, but admittedly not in EL7.
> >
> > Thanks,
> >
> > 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



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