Issue #3409: Deepin security review request - fesco

fesco

#3409 Deepin security review request

Opened 2 months ago by adamwill. Modified a month ago

It's been in the news recently that SUSE removed deepin due to ongoing security issues, and attempts by the packager to bypass SUSE's security review process:

https://security.opensuse.org/2025/05/07/deepin-desktop-removal.html

In Fedora, deepin's packagers have not tried to bypass our security review process, but that isn't surprising, because we don't really have one. (SUSE has enforcement mechanisms like "you can't add sysctl or dbus or polkit things to a package without them being reviewed", that's what the packagers bypassed; we have no such policies or mechanisms).

I had a look through the issues referred to in the SUSE report, and it looks to me like they probably affect Fedora as well. For instance, the SUSE post links to https://bugzilla.suse.com/show_bug.cgi?id=1134132#c2 , which was the security review of the deepin-file-manager package, in which SUSE's security folks did detailed review of deepin-file-manager's dbus interface and the polkit rules that control access to it. AFAICT, we have just been shipping this package as-is all along, with no meaningful review (the package review does not appear to have considered security issues at all).

Upstream did gradually respond to some of the SUSE team's concerns over time, and we've been shipping new versions regularly, so the situation should have been gradually improving, but it clearly never reached a level that process was happy with, and we've been shipping it the whole time. The SUSE post's conclusion about deepin-file-manager, which we are shipping, is: "We did not get further responses for these reviews, and the components are still not whitelisted for openSUSE. Due to the frequent alteration of the D-Bus methods in the Deepin file manager daemon, which led to partial bugfixes and new issues appearing, we also refrained from assigning further CVEs for the issues. Formally, each incomplete bugfix would need a dedicated CVE, which would have led to a confusingly long list of CVEs revolving around the same topic: that the Deepin file manager daemon has major security issues, some of them likely still unfixed."

From a quick look through the other referenced components, we don't appear to be shipping several of them, but we do have deepin-api and deepin-system-monitor ("A second look that we had at the D-Bus service showed that it was once more using the deprecated UnixProcess subject for Polkit authentication in an unsafe way").

I suggest we try and apply a security review to our Deepin packages somehow (do a more thorough read over SUSE's and compare to our packages? Ask Red Hat security team to do it? Find Fedora resources? I don't know) and decide whether we ought to keep them.

This might also be a good juncture to ask ourselves why we are apparently a long way behind SUSE in terms of having policies and mechanisms for reviewing security-sensitive package changes.

adamwill commented 2 months ago

I'll also note there's a CVE bug on deepin-file-manager which never received a maintainer response.

adamwill commented 2 months ago

I should note I don't mean "the package review does not appear to have considered security issues at all" as a criticism of the reviewer, in particular; it is more a weakness in the process. The word "security" occurs zero times in our package review guidelines. We neither require package reviewers to consider security issues in any way, nor provide them with any tools or instructions for doing so.

ngompa commented 2 months ago

This might also be a good juncture to ask ourselves why we are apparently a long way behind SUSE in terms of having policies and mechanisms for reviewing security-sensitive package changes.

As someone who contributes to openSUSE, I'm aware of a couple key differences from Fedora:

All package builds have to pass rpmlint checks, and there is a tuned policy with scores and allow/deny lists for D-Bus and Polkit stuff. Package builds automatically fail if they have a sufficiently high "badness" score. (That means in Fedora parlance, you can't actually submit it as an update because it's marked as failed in Koji.)
SUSE Security is actively engaged as a stakeholder for package update submissions and have a defined process for triggering reviews. One such example of me going through this resulted in this review for DNF5.

Red Hat Cryptography and Security teams are not engaged with Fedora as a general rule. This has been true for at least the past decade (probably longer). Most of our security-related guidelines were deleted years ago when we realized there was ultimately nobody to care for them.

Edited 2 months ago by ngompa

decathorpe commented 2 months ago

This will be discussed during today's FESCo meeting (starting 17:00 UTC in #meeting:fedoraproject.org).

catanzaro commented 2 months ago

This might also be a good juncture to ask ourselves why we are apparently a long way behind SUSE in terms of having policies and mechanisms for reviewing security-sensitive package changes.

This is more important than what we do with Deepin itself.

I believe SUSE is the only distro that provides security reviews for security-critical components. I'm quite grateful to SUSE's security team for their findings, which benefit all distros. If Fedora were to start doing security reviews as well, that would surely be of great benefit.

decathorpe commented 2 months ago