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

81–90 of 131 posts

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

#81

Post by fulafel »

throwa356262 wrote: post #80
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…

I love multipass. It is a simple no BS virtualization solution and probably the best thing to come out of Ubuntu after LXD. But I can't use it. You know why? Because despite being open source Canonical wont tell you how to compile it and install it as a standalone program. Instead all their documentation says "install via snap"... even if your are on fedora or debian or arch: https://github.com/canonical/multipass Sn…

They do document how to build and run, in the OS specific build docs. Eg this: https://github.com/canonical/multipass/blob/main/BUILD.linux...

I think pointing end users to use the end user packaged app is fine, as is to trust people who are comfortable with building from source to find the build docs from the repo.

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

#82

Post by simoncion »

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

Earlier quoted context omitted.

> When will these distros accept suid was a mistake and disable it. I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode . 1) Do you believe that this program is unsafe when compiled and set suid root? 2) How do you propose that I replace it with something that isn't suid root? #include #include #include #include void maybe_do(const char * cmd) { if(system(cmd))…

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) Use a package that has several-thousand lines of C (and who knows how many lines of Python) running as root and does way more than I need.

All of these alternatives tell a story:

  The alternative to running ~five lines of C as root is to run *many* more lines as root.
This is kinda my point. Some people rave about setuid programs and assert that they should not exist, but when you absolutely need to let an unprivileged user do things that only root is ordinarily permitted to do you're going to have to have code running as root. And when you have code running as root, you have to be careful to get it right. Whether it's running from a setuid root-owned executable, a persistent daemon running as root, or a regular program that sudo [1] has executed as root is irrelevant: it's all code running as root!

[0] People shit on sudo for both being setuid root and for being "too complicated". I love the hell out of the program; it's an essential part of how I get shit done on my PC. sudo is -very seriously- a great tool.

[1] ...or similar...

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

#83

Post by simoncion »

charcircuit wrote: post #69
simoncion wrote: post #56

Earlier quoted context omitted.

> When will these distros accept suid was a mistake and disable it. I have the following C program that I use as an unprivileged user to put my system into and out of Game Mode . 1) Do you believe that this program is unsafe when compiled and set suid root? 2) How do you propose that I replace it with something that isn't suid root? #include #include #include #include void maybe_do(const char * cmd) { if(system(cmd))…

1) I believe the current iteration you have of it is safe. 2) I suggest that a service is created for managing system performance that exposes an API to your user to turn on and off game mode.

My commentary here [0] directly relates to your #2.

[0] https://news.ycombinator.com/item?id=47436085>

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

#84

Post by charcircuit »

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…

>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 direction away from only giving the minimal amount of privileges to the code that needs it.

>3)

See my response to 1). Making programs with different capabilities able to talk to each other should be made dead easy to do.

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

#85

Post by atwrk »

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…

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

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

#86

Post by simoncion »

charcircuit wrote: post #84
simoncion wrote: post #82

Earlier quoted context omitted.

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…

>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 that you don't actually have problems with setuid-root executables.

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

#87

Post by Sander_Marechal »

atwrk wrote: post #85
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…

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.

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

#88

Post by magicalhippo »

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?

> How else would that work?

Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.

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

#89

Post by magicalhippo »

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…

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

Post reply on HN