Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

blog.qualys.com

Post reply on HN
Print view View original

91–100 of 131 posts

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#91

Post by rlpb »

ifh-hn wrote: post #4

I wonder if, and this is just speculating not trying to start an arguement, if this sort of thing could have happened in the simpler pre-snap, pre-systemd systems? More to the point is this a cause of using more complicated software?

It absolutely could have happened when the ecosystem norm is `curl https://third.party/installer|sudo sh`. That was the normal method for third parties to ship software before snaps came along.

We have Flatpaks to solve this problem too now, but AFAICT while Flatpaks do support sandboxing the UX for that is such that most Flatpak non-power-users aren't enforcing sandboxing on Flatpaks they install, so in practice the feature isn't present where it's most needed.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#92

Post by sigmoid10 »

Sander_Marechal wrote: post #87
atwrk wrote: post #85

Earlier quoted context omitted.

Have you tried Debian with the XCFE desktop? Should be pretty similar to Xubuntu (but without Snap, of course)

I second Debian. All the good bits of Ubuntu have long since been ported back to Debian, and it has much more timely releases now.

Me too. Switching my home system from Ubuntu back to Debian was influenced a lot by snap. I don't get how they could fumble that one so hard. It goes against everything they used to stand for. If I want a bloated, slow, closed-source, proprietary app store with unclear security ramifications, I'll install MacOS or Windows. It also feels like app developers at least care a little bit about those stores. Mozilla for example still officially recommends installing their Debian package rather than through snap on Linux, despite shipping via snap by default on Ubuntu now.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#93

Post by NekkoDroid »

yjftsjthsd-h wrote: post #72
NekkoDroid wrote: post #36

Earlier quoted context omitted.

Probably never for package based distros. I could see it happening for image based distros, where systemd is slowly but surely providing all the building blocks for. It has had the option for `NoNewPrivileges=` in the `system.conf` since v239, so it isn't exactly difficult to disable for the entire system. Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, g…

> how many binaries are suid binaries while they probably shouldn't be (passwd I would expect an unprivileged user to be able to change their own password. How else would that work?

systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#94

Post by littlecranky67 »

usr1106 wrote: post #77

I don't like snap and have always uninstalled it in the past. However, that gets more difficult in newer releases, so probably not a sustainable path. Still searching for the distro I could install instead of Xubuntu for friends and family who don't want or need the latest and greatest. The main reason for my dislike is the closed source nature of snap distribution. App isolation is important and not easy. That bugs…

Pop!_OS is basically Ubuntu without snap. Debian is fine, but for some reason it is ugly. Like, you can style and configure it with a thousand options, but simply fails to have a nice theme and UI out of the box.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#95

Post by zyga »

thayne wrote: post #34

Why does snap-confine need to be setuid, rather than use a user namespace?

There are several reasons but at some point we can use user namespaces to remove them. I'm not particularly a HN person so I won't go into details but it's possible to drop the setuid bits sooner rather than later.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#96

Post by ndsipa_pomu »

tialaramex wrote: post #59
unethical_ban wrote: post #48

Earlier quoted context omitted.

Is a race condition a memory related error?

No. Race conditions are a normal part of our world, in the same way it's not a memory error if you coded the discount feature so that people can apply more than one 10% off coupon to an order and as a result the nine different "10% off" offers that marketing seeded have summed to a 90% discount which bankrupts you. An example race condition would be Mike and Sarah both wake up, notice there's no milk and decide to gr…

I like your idea of illustrating a race condition with buying milk - that should become the default method of explaining them. (Either that or bartenders serving customers which is my usual method of understanding work queues)

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#97

Post by TZubiri »

stevenhuang wrote: post #75
TZubiri wrote: post #73

Earlier quoted context omitted.

[flagged]

> based on ignorance and naivety. About as nuanced as your bait framing of what a mere language ought/can do. Oh you're a python backend developer, guess that explains it.

So I was saying that rust monolithicism is NOT based on ignorance and naivety.

Do you see what I mean by nuance? I think you just glanced at the comment, saw that there were negative words around rust, and you lossy compressed into "Rust bad".

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#98

Post by Xiol »

usr1106 wrote: post #77

I don't like snap and have always uninstalled it in the past. However, that gets more difficult in newer releases, so probably not a sustainable path. Still searching for the distro I could install instead of Xubuntu for friends and family who don't want or need the latest and greatest. The main reason for my dislike is the closed source nature of snap distribution. App isolation is important and not easy. That bugs…

Worth looking at Fedora. Been using it for work and play for over a decade and it's never let me down. Absolutely solid.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#99

Post by throwawayqqq11 »

fc417fc802 wrote: post #79
nine_k wrote: post #65

Earlier quoted context omitted.

But this vulnerability is enabled by a very creative exploitation of the complicated bind mounting scheme used by snap-confine. Just reading about these mounts between /usr/lib to /tmp and back triggered my sense of a potential security vulnerability.

Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaini…

When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no?

The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.

Re: CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root

#100

Post by fc417fc802 »

throwawayqqq11 wrote: post #99
fc417fc802 wrote: post #79

Earlier quoted context omitted.

Slightly tangential but I never ended up switching to nix (or guix) precisely because I don't fully understand the theory behind why things were done the way they were done and where the security boundaries are supposed to lie relative to a "regular" distro. I found plenty of prescriptive documentation giving me recipes to do anything I might be interested in doing but not much in the way of design documents explaini…

When you sandbox your apps on debian already, there should be no security difference doing so on nixos, no? The globally accessible /nix/store is frigthening, but read-only. Same applies to the nixos symlinks pointing there. This vulnerability was enabled by a writable /tmp and a root process reaching into it. This would be bad on debian and nixos.

I'm not suggesting the presence of a vulnerability just that I'm not comfortable switching to a complex system where I have little to no understanding of the logic behind the design. My remarks were nothing more than a tangential gripe.
Post reply on HN