CVE-2026-3888: Important Snap Flaw Enables Local Privilege Escalation to Root (opens in new tab)

Might be worth updating the link.

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

Snap needs to die, it is hurting everybody including canonical

If you need metadata added by NVD, NVD website documents their API.

I remember cron jobs that did what systemd-tmpfiles-clean does before it existed. All unix daemons using /tmp run the risk of misusing /tmp. I don't know snap well enough to say anything about it makes it uniquely more susceptible to that.

Less pithy, i seem to recall many issue with programs that relied on suid and permission dropping, which would be the 'oldschool' way of firming up the above.

You're not wrong that complexity has been introduced, and I'm not a a fan of snap either, but ultimately sandboxes (esp backwards compatible ones that don't need source level modifications) are complex.

If you want simple and secure, you're probably looking at OpenBSD and pledge.

The problem is snapd not protecting against something else writing to /tmp.

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.

The answer is definitely "yes". Many articles and books have been written about UNIX administration, and separating accounts, even without jails.

With jails, you could do even better.

Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, groupmems, ...), though alot can also work without being suid just more resticted in what they can do.

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 <string.h>
  #include <stdlib.h>
  #include <stdio.h>
  #include <unistd.h>
  
  void maybe_do(const char * cmd) {
    if(system(cmd)) {
      perror(cmd);
      exit(2);
    }
  }
  
  int main(int argc, char** argv) {
    if(argc != 2) {
      return 1;
    }
    int turnOff = strncmp("on", argv[1], 2);
  
    if(setuid(0)) {
      perror("uid");
      return 2;
    }
    if(turnOff) {
      maybe_do("/usr/bin/cpupower frequency-set --governor schedutil > /dev/null");
      maybe_do("/bin/echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level");
    } else {
      maybe_do("/usr/bin/cpupower frequency-set --governor performance > /dev/null");
      maybe_do("/bin/echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level");
    }
    return 0;
  }

On a lot (at this point I assume most) of systems /tmp is also just a tmpfs, so it also is just in memory. /var/tmp usually is storage backed though.

There kind of is. /run/user/$userId is part of a tmpfs and is owned by the user. But it isn't always used when it should be.

Systemd also has a mechanism to create private /tmp directories for services.

https://askubuntu.com/questions/431058/using-a-cronjob-to-cl...

If you miss that "will this eat my system?" adrenaline rush you get from systemd-tmpfiles, you could just use cron + find, but replace xargs with the -delete option.

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.

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

However, I've been extremely happy with Devuan. It is Debian minus some bad decisions the Ubuntu voting block forced upstream (for instance, there's no systemd).

They really went out of their way to make it awkward and annoying to take snap out.