Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
Ubuntu

Memory-Safe Sudo To Become the Default In Ubuntu 80

Posted by BeauHD from the safer-and-more-resilient dept.
Longtime Slashdot reader RoccamOccam shares a blog post from the Trifecta Tech Foundation, a nonprofit organization that creates secure, open source building blocks for infrastructure software. The foundation is also the developer behind Sudo-rs. From the report: Ubuntu 25.10 is set to adopt sudo-rs by default. Sudo-rs is a memory-safe reimplementation of the widely-used sudo utility, written in the Rust programming language. This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. [...]

The decision to adopt sudo-rs is in line with Canonical's commitment to Carefully But Purposefully increase the resilience of critical system software, by adopting Rust. Rust is a programming language with strong memory safety guarantees that eliminates many of the vulnerabilities that have historically plagued traditional C-based software. Sudo-rs is part of the Trifecta Tech Foundation's Privilege Boundary initiative, which aims to handle privilege escalation with memory-safe alternatives.

Memory-Safe Sudo To Become the Default In Ubuntu More | Reply

Memory-Safe Sudo To Become the Default In Ubuntu

Comments Filter:

  • Although I would like sudo that is formally verified, not simply memory safe. Maybe something worth doing in Ada/SPARK.

  • As long as.... (Score:5, Funny)

    by PhantomHarlock ( 189617 ) on Tuesday May 06, 2025 @06:45PM (#65357441)

    ...it can still make me a sandwich we're good.

  • Could someone explain to a ânon-coderâ(TM) what this means in laymanâ(TM)s terms please. ;)

  • Welp (Score:3)

    by jrnvk ( 4197967 ) on Tuesday May 06, 2025 @06:56PM (#65357457)

    This is probably gonna break some of my 20-year-old plus scripts

    • I'm thinking it's in addition to sudo; able to change back to sudo as default

    • Re: (Score:2)

      by caseih ( 160668 )

      Meh. The big distros have already deprecated sudo in favor of policykit (which has not yet been re-written in rust).

      • Re: (Score:2)

        by thogard ( 43403 )

        Sun tried that 25 years ago and even today it is hard to find correct examples of how to create the configuration to make it useful. There were a lot of good things in Trusted Solaris that never got used even in most places that decided they needed the "Trusted" version.

    • Yes, it may break things [github.com], although it's drop-in compatible for the subset of sudo functionality it implements. I'm not sure if Ubuntu will migrate everyone by default on upgrade, but they'll almost certainly keep the original sudo as an option for people that need it.

      • Rust has crept into the Python ecosystem and now a lot of things that were totally platform independent only work on platforms with rust, which to me means only Linux.

    • Re: (Score:1)

      by wed128 ( 722152 )
      If your 20 year old scripts rely on sudo, they're already broken. Fix your permissions.

      • Re:Welp (Score:4, Informative)

        by DamnOregonian ( 963763 ) on Wednesday May 07, 2025 @12:04AM (#65358063)
        lol, are you serious?

        How do you think permissions are obtained in linux?
        Sure, some things can be snuck around with capset(2), others can be handled with fine-grained filesystem permissions, but otherwise, you need to come in as root and drop perms.
        Are you suggesting that we should just suid the script?

        • Re: (Score:1)

          by wed128 ( 722152 )
          No, that's exactly not what I'm suggesting. What I'm suggesting is that the common use of sudo to get permissions to do whatever you want to do is a security nightmare, and amounts to lighting a cigarette with a flamethrower. If your script needs to do network things, use capset on the binary that does it and then have the binary owned and only executable by a group that allows that operation. there are very few things that definitively need root, and using sudo to get root permissions is overkill in almost

  • Great, but ... (Score:3)

    by PPH ( 736903 ) on Tuesday May 06, 2025 @06:56PM (#65357459)

    ... how much of the Rust environment will I have to install just to fix this one bad sudo executable?

    • Avoiding dangers of dependency explosions (Score:1)

      by Anonymous Coward

      This blog post discusses the risk of depending on dozens of unstable packages, not uncommon for programs written in modern languages:

      Sudo-rs dependencies: when less is better [memorysafety.org]

      The sudo utility represents a critical privilege boundary, so it should be memory safe. [...] Ruben Nijveld from the Tweede golf team offers his perspective here on one of the greatest challenges we faced when developing software that can be widely adopted: Rust crate dependencies.

      When sudo-rs development started, we added several dependencies using Rust's crates ecosystem to quickly ramp up development. During development we accrued approximately 135 transitive (direct and indirect) dependencies. Once this was identified, we managed to reduce our total dependencies down to three. In this blog, we explain why and how we did this.

      The remaining dependencies are the core crates libc, glob, and log.

    • Re: (Score:3, Informative)

      by atomic_gingerbread ( 10452204 )
      Rust executables are typically built with all rust modules statically linked, so only dependencies on libc and other system libraries remain:

      $ ldd `which sudo-rs`
      linux-vdso.so.1 (0x000072fbe0db3000)
      libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x000072fbe0cb6000)
      libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000072fbe0c88000)
      libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000072fbe0b9f000)
      libc.so.6 => /lib/x86_64-

      • Re: (Score:2)

        by caseih ( 160668 )

        Nice, but that is not what the OP was asking about.

        • The immediate implication of my comment is that no "Rust environment" needs to be installed for the sudo-rs executable to function. I guess you could consider statically linked code an "environment", but at any rate it doesn't pull in a bunch of dependencies from the package system that you would get with e.g. a Java or Node application.

          • To nitpick a little bit: a Java Application, would come with its own Java runtime.
            That is what the word "Application" implies.
            So: again nothing to install. It comes with what ever package manager you are choosing - automatically - or is inside of the package - preferably.

        • Re: (Score:2)

          by PPH ( 736903 )

          I got two different answers, both useful.

          1) For someone who is unfamiliar with Rust, it appears that it can be statically linked to existing libraries. Good ... but that opens up the question of how secure a sudo.rs executable can be if an attack surface exists in someplace like libc.so (the 'old fashioned' C implementation). If I understood this response incorrectly, then:

          2) A project to 'Rustify' any existing executable will be an involved job. Here (https://www.memorysafety.org/blog/reducing-dependenci [memorysafety.org]

          • it appears that it can be statically linked to existing libraries. Good

            Not good.

            std:: is full of unsafe code. Statically linked binaries will never have patched std:: applied to them until they are recompiled.
            I'm sure this will be shipped with a dynamically loaded, and more importantly- able to be updated- libstd-rust. There have been security vulnerabilities caused by unsafe code in std:: before, and there will be again.

        • Actually that was what OP asked about.
          As OP did not understand his own question.

          So, to answer your hidden question and to expand on the answer you answered to:
          there is nothing to install to run sudo-rs, as everything that is not on your system is hard linked and every *.so it needs: is already on your system.

          And that would be/should be a no brainer but alas, people in our times know nothing about "how computers work".

  • Is the claim that current sudo is not memory safe? (Score:5, Informative)

    by moglito ( 1355533 ) on Tuesday May 06, 2025 @07:08PM (#65357485)
    I find the title misleading. It suggests that the current sudo is not memory-safe, while in reality it is just not written in a memory-safe language. That attribute means very different things when talking about a language and a program. It honestly seems a bit arrogant from the Rust-fan-block to use that description, as if programs could not be memory safe unless they are written in a language that guarantees memory safety.

  • I use su like god intended.

    • So, sudo su me.

    • Me too. I known what I'm doing.

    • I use su like god intended.

      Me too. The thing is, users who are not Linux-savvy tend to use 'sudo' because they were told to. Then they tend to use it all the time, even when it shouldn't be used.

    • So when a customer comes up to you and says they need to run one command and it needs to run as root, you give them the root password?

      • Re: (Score:2)

        by BuGless ( 31232 )

        Of course not.
        The ancient and still trusted solution is to:
        - Create a new user account for that, give the password to that account to the user in question.
        - Create a shell script that performs the actions without introducing security issues.
        - Put that script as the login shell for that user.
        Q.E.D.

        Sudo is for whimps.
        Trying to rewrite it to be memory safe is like mandating safety goggles for chainsaw operators.
        Will it make it safer to use it? Sure, slightly.
        Was it safe to begin with? Not really, handling ch

        • Shell scripts without security issues are impossible.
          That is why it is a no, no!, No!, NO! to write setuid shell scripts.

          Modern shells can mitigate a little bit ... but only a little bit.

          The correct way if a user wants to do something that requires root: he writes a ticket.
          And you do it. If the "you do it" requires more than a single command: you write a script.
          Commit the script, and put the commit log (or even the script) into the ticket when you close it.
          Usually in a sane organization, the version control

          • Shell scripts without security issues are impossible.

            That depends. Do they need to take input? Then yes, they are impossible. Otherwise, they are very possible. Simply don't use any variables. For any complex problem this is not feasible. For just running a command as a specific user, it works fine.

        • Your solution doesn't scale to an environment with thousands of apps and users. Many applications install as root and there's no option to create a user with the access because it needs root, period, and it is unavoidable. So what happens is, the handful of people with root access end up running around doing things for other people all the time.

          Furthermore, how do you handle the password for the user you created? Maybe you have secured root but you can't just trust a team of people to share a single pas
  • That's great, now your doohickey is memory safe. Which sounds like a good idea to me.
    But why not just get rid of the doohickey completely, and waste less of your time and cognitive ability on something you don't need in the first place.

    • Re: (Score:2)

      by Jeremi ( 14640 )

      If you're claiming that sudo is unnecessary, you should probably also give some hints about how one could accomplish the tasks people currently use sudo for, without using some variant of sudo.

    • Whoa! Did they finally fix fine-grained permissions in the kernel?! That's amazing!
      I look forward to never having to drop privs again!

      Or I wonder... if you just have no fucking idea what you're talking about.

  • ... Please remmeber that GNU is free (as in fredom) to fork sudo-rs, relicense it as GPL and mantain the fork, meanwhile, if one forks GPL code, one is NOT FREE to re-license it.

    So, if one is worried about GNU/Linux (or Ubuntu, specifically) being less GNU and less GPL by the minute, then get forking, re-licensing and maintaining.

    This in not a ploy to make linux "less free", is just linux evolving into a new codebase, in a more modern and (allegedly) more safe language.

    JM2C
    YMMV

  • What was wrong with the current / usual sudo?
    • > Memory-Safe Sudo To Become the Default In Ubuntu
      should be
      > "Memory-Safe" Sudo To Become the Default In Ubuntu
      or rather
      > Rust Sudo To Become the Default In Ubuntu
  • I canâ(TM)t think of a single time I have ever questioned the memory safety of sudo
  • "Rust will never be in linux."

    "Rust will never be a major part of linux."

    "There is no way the linux people will allow rust."

    "Rust is still just a toy, entirely not proven, it will be decades before it is trusted."

    "Rust is still very much in beta, and not really used in production."
    • I doubt that C and C++ programmers quote the same things, and I bet most C and linux programmers could easily substitute "Rust" with "C++" in your quotes, except for the last two:

      "Rust is still just a toy, entirely not proven, it will be decades before it is trusted."

      "Rust is still very much in beta, and not really used in production."

      C++ is a toy used in production, producing decades worth of defective code, it will never be trusted.

      After 3 months of learning Rust, my impression is that Rust's beta is much better than C++'s maturity. Take operator overloading as an example, for types like polynomials that use heap allocation. Rust does this correctly, so in

      • Going out on a limb here, but maybe don't do arithmetic with dereferenced pointers?

        • The & symbol in Rust is not a "dereferenced pointer." &a + &b is not pointer arithmetic. &a means that you use "a" by read-only reference (without copying it or modifying it). Therefore, it makes perfect sense to use it for arithmetic, even though it looks a bit strange. The operation will use the existing values without copying them or modifying them, and produce a new value. There is a complication, that the result of the computation is a value, not a reference, so to cover all situati

      • The destructor will deallocate it.
        If you write the code in a way that the variable never gets "out of scope", then the destructor is not called.
        If that is your question.

        Seems you made your code artificial complex that standard C++ is not able to deallocate unused variables/memory.

        What the funk that has to do with "operator overloading" is beyond me.

      • Can this be done with C++? I tried decades ago and gave up.

        C++ has always been able to do this. I've been using C++ since the mid 1990s and it's always been able to do that.

  • So Canonical has broken a bunch of functionality that used to work perfectly well in older Ubuntu versions. Do they focus on fixing it? Do they instead add new functionality to make things more user-friendly and generally better? No, they change sudo, which works absolutely fine, at least I've never had a single problem with, to its rewrite in Rust. Because it's a cool new thing.

    Honestly, up until recently Ubuntu was the default Linux distro for me, now I'm not so sure. It's not an option to replace it righ

  • However, it may be me, and point me to this if u am wrong, but where's the actual list of things that are broken in sudo? I am thinking if there was a list, then maybe the folk who maintain sudo might get to fixing them. Or at the least, sad individuals like myself, could use sudo with a bit more idea of the mayhem we might be causing.

Slashdot Top Deals

The confusion of a staff member is measured by the length of his memos. -- New York Times, Jan. 20, 1981

Close