CUPS and all of the other "root but with chroot" daemons like Postfix use a legacy security model that will hopefully be modernized to use things like namespaces and cgroups. Hopefully this is a wake up call to start pursuing these migrations faster. Right now it's really painful to get Postfix and friends to not run as root, and the maintainers are very hostile towards enabling this behavior.
You can already sandbox services very effectively when you run them under systemd.
It’s really nice to be able to harden things solely through systemd.
> and the maintainers are very hostile towards enabling this behavior.
Got any links to read more?
I remember Ubuntu's decision to abandon its original "no open ports in the default install" policy for the sake of zeroconf/mdns was controversial at the time.
https://wiki.ubuntu.com/ZeroConfPolicySpec https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019...
Canonicals little jab under the "importance of coordinated disclosure" section rubs me the wrong way. They seem to be under the impression the recipient of a vulnerability report gets to set the rules, much like when a project receives a bug report. They don't. That power rests solely with the researcher, and they can do as they see fit.
> That power rests solely with the researcher, and they can do as they see fit.
That's true by definition, but there is still a "right way" and a "wrong way" to disclose if you don't want people to consider you an asshole. To be clear, not familiar enough to with this situation to say what happened, but I think it's totally fine for Canonical to call this out.
As a security researcher myself, we've been having the discussion about "right way" and "wrong way" for a long time. The consensus so far is that there is no consensus, and what the "right way" is changes. When Google Project Zero started doing 90 day disclosure deadlines, many viewed this as the wrong way and irresponsible. Now it's viewed as the only way to do disclosures.
You’re conflating power and proper practice. “Yeah, well, they’re allowed to” is a comment that’s never, ever worth making, because EVERYONE already knows it. The need to always kick up a fuss about “doing whatever I want in my land” always feels like a weirdly American reflex that’s always a little ignorant of the context of the actual discussion taking place.
You're making it sound like there is a well-agreed-upon way of disclosing vulnerabilities ("_proper_ practice"). I'm a security researcher and this particular discussion has been going on for well over a decade at this point.
My point wasn't "they're allowed to do whatever they want". My point was there are many different viewpoints on the matter and Canonical seems to be insisting theirs is the correct one.
(Also, I'm not American)
Canonical's statement hits all the right notes. It's a short summary of what coordinated disclosure is and a gentle reminder of why it's important to follow that practice, without really pointing any fingers. I don't see something in Canonical's actions that suggests they actively harmed the process, or that the way the early disclosure was handled was in the users' interest.
You say it "rubs you the wrong way" without pointing out what exactly you think is wrong with it. One could easily understand that as a security researcher you just want to do whatever you want, when you want it, without anyone pointing fingers at you.
Your attitude that "That power rests solely with the researcher, and they can do as they see fit" while technically correct exudes bad faith. Further explanation that "there's no consensus" isn't making it any better.
Attacking UNIX Systems via CUPS, Part I, 2024-09-26 (linked at end of page)
https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems...
This morning I just installed the fixed Slackware Packages for cups. It became available on Oct 1 18:00 UTC:
>(* Security fix *)
>patches/packages/cups-filters-1.28.17-x86_64-2_slack15.0.txz: Rebuilt. Mitigate security issue that could lead to a denial of service or the execution of arbitrary code. Rebuilt with --with-browseremoteprotocols=none to disable incoming connections, since this daemon has been shown to be insecure. If you actually use cups-browsed, be sure to install the new /etc/cups/cups-browsed.conf.new containing this line:
>BrowseRemoteProtocols none
>For more information, see:
JSless alternative https://nvd.nist.gov/vuln/detail/CVE-2024-47176