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

111–120 of 131 posts

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

#111

Post by drysart »

simoncion wrote: post #82
c-hendricks wrote: post #66

Earlier quoted context omitted.

Run the part that needs root as a daemon, some server that accepts http requests Use sudo and allow anyone to run the binary without password auth Use the existing gamemode package Those are a few options, of course it's your system in the end

First off, thanks very much for giving me exactly what I asked for. You propose that instead of sometimes running ~five lines of C as root, I do one of the following: 1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in. 2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs. 3) Us…

Hopping in here to suggest that instead of running a persistent whole-ass daemon, you could just configure a systemd service, set it up to trigger off a write to a fifo, and then use filesystem permissions to restrict access to who can write to the fifo to whatever user/group should be allowed to perform the operation. (You can also do it by giving those users sudo access specifically to be able to trigger the service via systemctl; but if our goal here is to eliminate the use of setuid then any solution that uses sudo fails the assignment).

The systemd service executable is just your simple C program as-is.

Persistent whole-ass daemons aren't really the way it should be done even over in Windows, because in Windows you can attach ACLs to give permissions to start a Windows service to any arbitrary users that should be able to do so; which is spiritually equivalent to the Linuxy systemd solution.

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

#112

Post by charcircuit »

simoncion wrote: post #86
charcircuit wrote: post #84

Earlier quoted context omitted.

>1) Building services should be easy. The fact that Linux does not have an easy to use IPC mechanism is the fault of Linux. Yes, systemd can make it so services don't have to run until they are connected, and yes dbus exists, but it's overcomplicated for something which should be easy to make. This is a Linux devex failure. >2) I agree this is going in the wrong direction. Full sudo is also even more in the wrong dir…

> The fact that Linux does not have an easy to use IPC mechanism... What? Send bytes down a UNIX socket. There's nothing easier, really. It's so simple, it's what systemd uses to have monitored daemons indicate that they're now actually running. The rest of your commentary has nothing to do with my commentary about unprivved users running code as root. Given the failure to address my on-topic commentary, I'll assume…

>There's nothing easier, really. It's so simple

It really isn't. You have to a whole protocol on top of it if you want to use it and then build out the daemon logic yourself. If it was so easy why didn't you write it instead of making a suid binary. The complexity is not sufficiently abstracted away.

>Given the failure to address my on-topic commentary, I'll assume that you don't actually have problems with setuid-root executables.

My whole response was addressing the core of your argument in your post "The alternative to running ~five lines of C as root is to run many more lines as root." The reason it's many more lines is because the Linux developers did not write abstractions to make it simple to do. If you read my original post in this comment chain you will see that I do have problems with setuid executables and want distros to disable them.

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

#114

Post by linsomniac »

aidenn0 wrote: post #46

systemd-tmpfiles bugs the heck out of me. It breaks so many applications for absolutely no good reason. A typical system of mine not running it gathers less than 1GiB per year of uptime in /tmp with disk sizes measured in TB. Even if you are /tmp on a 256GB NVME, that's less than 1% of your total disk per year of uptime. If you upgrade to alternating Ubuntu LTS editions (which requires a reboot every 4 years) systemd…

>which requires a reboot every 4 years

We have a monitoring check and once a system reaches 200 days of uptime we start scheduling a reboot. Because you KNOW there are kernel and library updates that are probably hanging around on disc but not in memory. I used to be an uptime snob, but I've decided it does more harm than good.

Slightly related: A coworker was doing a RAM upgrade on a Sun box. I suggested that before they cracked the hardware open, they first shut it down, and then power it back on, just to make sure it would. So they wouldn't go chasing down a RAM upgrade issue when it was the system itself. I want to say that this system had years of uptime since it was last rebooted, let alone powered off. He was very glad I suggested that, because it indeed did not come back up after the power cycle.

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

#115

Post by linsomniac »

kev009 wrote: post #38

I always wonder why Ubuntu is even on the radar anymore. It is a pile of questionable decisions with a billionaire ego bus factor. If you like apt, just use Debian. sid is fine for desktops if you are moderately technical.

>Ubuntu is even on the radar anymore

The biggest thing that has prevented me from switching prod systems to Debian is that the window for updates is fairly small, at around a year. 13 came out Aug 9, 2025, and 12 goes EOL June 10, 2026. Compared to Ubuntu 24.04 coming out in April 2024, and 22.04 goes EOL in May 2027 (a year after 24.04). So Ubuntu covers 2 releases plus a year.

I know a lot of people feel like this isn't a big deal, but even with Ansible it can be hard to get our fleet of a few hundred machines all upgraded in a year window, being already busy. Some of them are easy, of course, but there are some that take significant time and also involve developer work, etc...

Don't get me wrong, I think Debian is great. But in the data center, there's definitely a case for a longer support window, and I like that about Ubuntu. RHEL is even better for that, but it is very nice that Ubuntu free and Ubuntu commercial are the same, but with RHEL there is that split to CentOS being the free one (haven't used RHELs in quite a while, obviously).

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

#116

Post by linsomniac »

kam wrote: post #76
yjftsjthsd-h wrote: post #72

Earlier quoted context omitted.

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

Send a message to a socket-activated daemon running as a UID with write access to the password database.

Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.

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

#117

Post by jkrejcha »

simoncion wrote: post #82
c-hendricks wrote: post #66

Earlier quoted context omitted.

Run the part that needs root as a daemon, some server that accepts http requests Use sudo and allow anyone to run the binary without password auth Use the existing gamemode package Those are a few options, of course it's your system in the end

First off, thanks very much for giving me exactly what I asked for. You propose that instead of sometimes running ~five lines of C as root, I do one of the following: 1) Run a persistent whole-ass daemon using something for IPC... maybe DBUS, maybe HTTP, and all the code that that pulls in. 2) Use a setuid root program [0] to run the entire program as root, rather than just the ~five lines that need root privs. 3) Us…

I think the only thing that I find kinda strange about setuid/setgid is the fact that it is tied to an executable rather than as part of the executing principal.

As an example of an OS that doesn't use a concept, Windows only recently got Unix domain sockets (which is kinda the standard for IPC in *nix land) and generally used named pipes, mailslots, etc for IPC, which can be ACLed. Communication with services and elevation after Windows XP[1] was based on the the user's privileges and not "uid == 0" or "bit set on a file"

[1]: Before Vista, a lot of services actually straight up did show UIs on the desktop or whatnot. It was found though that doing this was pretty bad as you could use automation tools to drive the UI and it could lead to some pretty nasty local privilege escalations.

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

#118

Post by jkrejcha »

simoncion wrote: post #104
magicalhippo wrote: post #89

Earlier quoted context omitted.

> 1) Run a persistent whole-ass daemon using something for IPC This is the recommended way on Windows as well. Have the (privileged) installer install a privileged service, and have the non-privileged user program communicate with it.

> This is the recommended way on Windows as well. Quite possibly because there are something like two people on earth who understand the Impersonation machinery [0] and one of the two is likely to cause an HN Black Banner Event any day now... so there's no real 'sudo' or 'setuid' equivalent on NT. ;) [0] Seriously, it's fucking complicated . Decades ago, I wanted to write a sudo for the then-$DAYJOB. I gave up after…

In general, I think it's because it tends to be an XY problem. If you're on a service account or something, you generally have SeBackupPrivilege (override read ACLs) and SeRestorePrivilege (override write ACLs) and other relevant privileges so like if you're changing files that's less needed since you can overwrite the ACLs to the necessary files as needed

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

#119

Post by usr1106 »

Xiol wrote: post #98
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.

I know Fedora, although haven't used it recently anymore because it's not approved at my current job.

But is that something to use by non-geeks on really low end machines?

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

#120

Post by usr1106 »

Jnr wrote: post #107
sigmoid10 wrote: post #92

Earlier quoted context omitted.

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

Yes, Debian is great. But there is also Arch by the way :)

Sure, I like Arch. Did not consider it for completely non-technical users, though.
Post reply on HN