1. 50
  1.  

  2. 8
    <Mara> Isn't that because it's written in C and C is inherently unsafe even though hordes of "experts" decry otherwise?
    <Cadey> Don't say that, you'll incite the horde.
    

    This comment about removing sudo seemed a bit misplaced considering systemd and the linux kernel are also written in C. I get the practical issues, but this isn’t the only reason (or probably the main reason) to remove sudo.

    Another reason is because it might be over complicated for what most people need it for, which exacerbates any issues with C. I would say setuid is also risky even for safe languages as you need to have a deep understanding of lots of potential foot guns like TOCTOU races and file ownership. Minimizing the attack surface for privileged code is generally a good idea for any language.

    Thanks for posting/writing this.

    1. 3

      FWIW systemd and the linux kernel are at least trying to add Rust support for incrementally adding memory safety to important parts. I know of no such plans with sudo.

      1. 9

        This is rearranging deck chairs on the Titanic; we need to remove the ability to run unsafe code, not add new ways to hide unsafety. A memory space is like a water balloon, not a sponge; any violation of invariants can lead to complete compromise.

        1. 4

          There’s please which is a Rust alternative to sudo with some additional features. It did have some nasty cves a while ago though, but the author requested this audit which shows the right stuff to me (and they’re all fixed now).

          1. 6

            If the Rust fandom spent as much time writing new kernels and ecosystems as they do shitposting about C and trying to inject Rust elsewhere, we could’ve replaced Linux by now.

            1. 5

              I don’t think this is actually true, and in any case I don’t think replacing Linux is in and of itself a solution to the actual problem of memory-unsafe C software resulting in exploitable vulnerabilities. If you had an OS written in Rust (and that still had some concept of a root user), but the sudo binary was still written in C, and had an exploitable memory-safety vulnerability that allowed an attacker to get root privileges, that is still a security problem. And contrariwise if you leave linux the way it is but rewrite sudo in a memory-safe language, this greatly mitigates the memory-unsafety problem on existing systems without going to the immense trouble to replace Linux.

              1. 4

                Right, but it’s hard to escape the feeling that “it’s written in C” is an odd complaint to have about a single program sitting somewhere near the top of the userspace stack, in a post where virtually every single program that’s mentioned directly or indirectly – Linux (including Wireguard, which Tailscale is built on top of), ssh, auditd, coreutils – is written in C. Basically the only one that isn’t written in C is Nix itself, and even that one is C++.

                If – and I have no qualms with that claim – being written in C makes something inherently unsafe, then it’s probably worth contemplating the idea that this whole setup, with or without sudo, is inherently unsafe, from top to bottom. And replacing sudo, of all things in it, with something written in Rust (or any other memory-safe language, from Java to PHP and from Python to Visual Basic) is very much rearranging chairs on the Titanic’s deck.

                1. 2

                  Agreed (and it’s worth pointing out that writing a program in Rust doesn’t in and of itself guarantee that the program is free from exploitable security vulnerabilities - it just greatly mitigates an important class of such vulnerabilities). I do think it would be good if sudo were not written in C(/C++), but I think the same thing about every other program in the stack including Nix and the Linux kernel itself.

                  In any case, removing access to the sudo binary itself for users that don’t need to use it certainly couldn’t hurt, regardless of what programming language it’s written in. I wonder how this is implemented; i.e. what the nixos options security.sudo.enable or security.sudo.execWheelOnly are actually doing.

                2. 1

                  Heh, and deploying exploit mitigation techniques into the OS for running existing software doesn’t require rewriting anything at all.

          2. 3

            I have always thought “I should get into NixOS”, but people seem to have gripes with the Nix configuration language and I am really comfortable running Alpine on the small boxes I have.

            Do you think the tools that are made available are worth the learning curve? ilo Alpine li pona

            1. 20

              I used NixOS for a while on my laptop. It’s certainly worth trying, and not very difficult to install.

              Setting up services, tinkering with the main config, is easy enough.

              But if you want to go deeper than that, you’ll spend hours searching other people’s configuration because the documentation is poor.

              1. 4

                Ugh, yes, this is my single #1 complaint with the infrastructure by far. The poor documentation. I need to start taking notes and contributing back to the wiki.

                1. 2

                  Seems like Guix might be an option. At least they didn’t create a brand new configuration language..

                  1. 15

                    At least they didn’t create a brand new configuration language..

                    Note that although Guix didn’t create new syntax (they use lisp), you’d still need to learn the “language” defined by the Guix libraries. In the end, most of your time is spent figuring out Nix/Guix libraries, and very little time is spent on programming-language things like branching and arithmetic

                    1. 5

                      The biggest annoyances I’ve run into with Nix-as-a-language are the lack of static types and the fact that it doesn’t really have good support for managing state. The latter doesn’t usually present a problem, but occasionally if you want to generate a config file in a certain way it can be annoying.

                      But I think it helps that I already knew Haskell, so all the stuff like laziness and the syntax are super familiar.

                      1. 1

                        There really isn’t much of a “language” to learn. Guix configurations use scheme records for about 90 of any configuration a user will do and the rest is in g-expressions which is something like a new syntax that takes the place of embedded shell scripts in nix.

                  2. 8

                    On one hand, Nix is terrible. On the other hand, isn’t everything else worse? Guix is the only decent comparison, and personally I think Nix’s technical decisions are better. (So do they, given that they borrow the Nix store’s design wholesale!)

                    1. 2

                      How can they be better, if they are the same?

                    2. 6

                      NixOS is amazingly good for writing appliances. It also can be made to barf out docker images, which is nice.

                      1. 6

                        Coming from Void Linux, NixOS on a desktop machine… ilo NixOS li pona ala, la pali mute. It’s a lot of work for a functioning desktop, I think. But on the server NixOS is killer and fun, and makes configuration suuuuper simple. I only need my /etc/nixos and /src folders to migrate my server anywhere (though I’d have to bring along /data to keep my state).

                        1. 1

                          This is basically what I do. When I got my new laptop I considered Nix, but decided to stick with Arch because it was easier. I use NixOS for my Digitalocean nodes and am very glad I did.

                        2. 1

                          tl;dr: No, I went back to Void on the desktop and Alpine/Ubuntu on servers in almost all contexts

                          Purely anecdotal: I was all-in on Nix, both at home and at work, and drank copious amounts of the kool-aid.

                          As of today, it still runs on a few machines I’m too lazy to reformat, but it’s gone from all my interactive machines, and from all functions (be it NixOS on EC2, or Nix shells for developer workstations) at work.

                          My takeaway was basically: Nix(OS) makes 90% of things absolutely trivial, the next 8% significantly more difficult, and the remaining 2% anywhere from nightmarish to downright impossible. That latter 10% made it “cost” significantly more than, say, investing in other version locking tooling for developer workstations at work. At home, that remaining 10% just meant that I didn’t do some things (like play many Steam games) that I would otherwise have enjoyed doing, because I didn’t have the energy to dive in.

                        3. 1

                          aieeeee, your beautiful dark-theme website has become light! Tragedy! /s

                          Real talk though, I like the revised blog layout. (New since the last time I recall reading it, at least.) The smaller icons and IRC-style bolded names for the conversational bits make them flow a lot better with the actual text.

                          1. 4

                            Actually, that’s because your machine is set to light mode! My CSS is aware of that setting and matches what the user noted they preferred.

                            1. 1

                              I actually tried that before posting. XD I set Firefox to use a dark mode theme and it still gives me the same thing as the light theme? Even when I disable cache and visit the page in a private window. As far as I can tell, anyway. Seems to be loading gruvbox-dark.css though, so maybe it’s just my eyes not noticing the difference.

                              1. 2

                                Oh i mean at the OS level there’s usually a dark/light mode preference. That’s what my site reads from. In Linux this will be at the KDE/Gnome level but usually firefox lets you override that.