Is there an advantage of using doas over sudo

whyisthesheep@thelemmy.club to Linux@lemmy.ml – 102 points –

I see people talking about doas saying it's just like sudo but with less features. I'm just wondering if there is any situation where you should use doas or if it's just personal preference.

71

On the one hand, doas is simpler. Less code means less bugs, and lower chance someone manages to hack it and gain admin rights. On the other hand, sudo is more popular, and so has a lot more people double-checking its security. Ultimately, I don't think it matters - when someone unauthorized gains admin rights, usually it's not due to bug in sudo or doas, but other problems.

Well said. Check your firewalls, check your ssh config, liberally use user repositories, and always tip the guard (donate to GNU)

I use doas just because. It's not necessary at all, but it can't hurt either (I think). It might be a bit more secure (fewer features -> fewer code -> fewer bugs -> fewer vulnerabilities, need to give password more often). Kinda cool if you want more minimalism for fun (I replaced startx with sx...)

doas, afaik, was originally made for FreeBSD, so some of its features aren't compatible with/haven't been implemented for Linux. That may or may not be an important issue for you to consider.

Doas is more secure, sudo has had a few critical vulnerabilities in the past, because the codebase is much larger. Sudo has like a million features that most people don't need, but they significantly increase attack surface.

Doas is more secure, sudo has had a few critical vulnerabilities in the past, because

.. it's newer. You wanted to say "it's newer." It has nowhere near the history, and looks better because it's newer.

Please, now, trot out the "use sudo if you're old" memes, because we grew that skin extra thick over the systemd counter-hate.

I just use doas because sudo has a bunch of features i don't care about or use, and doas does everything i need while being significantly smaller.

Does the size of a 6kb program really make that much of a difference?

Side note: If I'm reading this right (ignoring dependencies) sudo is 6kb while doas is 14kb.

Sudo is 6 megabytes

Damn, that's like 4 floppies!

The concern is not storage space, but potential bugs leading to security issues. For OpenBSD this is very important, and so they made doas.

I understand the concern - but it's not warranted. LOC is a bad predictor of security. And fwiw /usr/bin/sudo on my system is only 227K.

The OpenBSD team does fantastic work. I'm assuming doas will be a good tool and probably more secure that sudo generally. But "size" isn't the best way to determine that. It's not even a good way.

Tedu (author of doas) wrote about it in 2015:
"There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough. (As shipped in OpenBSD, the compiled sudo was already five times larger than just about any other setuid program.)"
https://flak.tedunangst.com/post/doas

6,054.0 kB, not 6 vs 14.0 kB

Ya know, I wish I could at least say something about being european and using commas instead of periods for decimal points, but I can't even say that. Still 6MB fully installed is nothing these days.

And here I am wondering what went so wrong with sudo that it needs 6 fucking mibibytes to work its simple magic.

Yeah, it's gonna take forever to download over my 14.4k baud modem.

STOP PICKING UP THE PHONE MOM!

Less lines of code needed means less chances of errors and potential vulnerabilities (if number and quality of eyeballs were the same)

Also only really applies if you are comparing programs in the same programming language as some programs have lines that are significantly more expressive than others. Conversely, some languages have constructs that are significantly more bug-prone than others (e.g. for loops with explicit integer indices instead of higher order functions like map or iterators to iterate over a collection).

No, but it's cleaner and designed for my usecase, and no real work to setup for me, all I had to do was add an alias

When I thought about this question, I decided to ditch both sudo and doas entirely. I am certain this is an unpopular opinion, but I preferred setting up a granular permission + user system instead, and keeping root privileges for only a handful of use cases (primarily for system updates and package installations).

For anything else, a dedicated user is created, and given only permissions to do that exact thing only. Many of these users have no shell access at all, and for the ones that do, I use a password manager so I don't have to memorize passwords for all of these users.

Did you know that you can configure sudo to only grant access to specific programs?

Yes I did, and that's a very good point. What sudo does not allow me to do is grant a user access to modify or read specific files or directories. I can get both that and access to executing specific programs using a users/groups permission system.

Another thing I don't like about sudo is that you end up using the same password for everything, which is also the password for logging in. Putting higher privileges behind my same login password opens me to a single point of failure.

Why would a system update need privileges? What is the privileged action in pulling and applying updates your distro ships?

I mean, that's one of the things that definitely needs permissions, right? You're overwriting system config and executables for all users on your system. Otherwise a malicious actor could just replace firewall configs, or embed malicious code into your executables. If not /bin and /etc what else should need privileges?

On a mutable distro maybe but also no. You need to update your system, always. The updates come from the distro, and you only invoke your privileged package manager to do these changes for you. Its not privileged.

If a malicious actor is able to replace package repos that your package manager uses, for example an infected server in the same network, this would be the only way to inject arbitrary stuff by using dnf update or rpm-ostree update.

Installing software and updating the already existing is very different.

The short answer is that my distro did not let me do this easily. But that was for good reason.

A system update would require too many privileges that it would be almost indistinguishable from root.

Currently, every user I have is restricted in what files it has access to. A system update user would need access to so many files, including install locations of all binaries, and non-binary installation paths of all current and future programs I install (some package installs modify /var, many modify /etc, and so on).

This user will also have access to all these programs, down to system applications. It can trivially break a permission system I come up with.

It may be possible to restrict system updates to a user, but it would be such a powerful user that its not really worth it.

Does the user have that access? In my case with rpm-ostree they can just execute 2 commands rpm-ostree refresh-md (get updates) and rpm-ostree update. rpm-ostree rebase is used for system upgrades afaik, that one needs a password.

Only the root user has access to system updates on my system currently.

What does rpm-ostree update do exactly? Does it execute the update? Or is that the rebase command only?

No rpm-ostree downloads the diffs, applies existing changes (added or removed packages) and builds a new image that gets staged as first boot target. After reboot you are on an updated system.

If it builds a new image that replaces the entire system it could be compromised to give full access to the entire system just as easily as sudo, possibly more easily.

No it just pulls the ostree / OCI image from the fedora image registry and applies changes that need sudo privileges to change, remove etc.

Deploying a different image is not allowed.

See this issue for details

The component that is like sudo in this case is polkit. Of course an unprivileged user can be used to run sudo commands as well, limited by the rules in the sudo config file, just as these polkit rules limit what the user can do...as long as there is no security issue in sudo and polkit respectively but the actual work is done by a privileged process that is merely controlled by the commands given by the unprivileged user.

Yes thats the point, the specific actions are a good way to act like a firewall for the access to the privileged process, invoked by anyone.

This is brilliant, as unprivileged users over ssh, or not even logged in, can invoke the updates in that case, making a "grandma pc" that is immutable and autoupdating possible.

See this discussion on how it would eventually be implemented

I see. I have little knowledge, but I bet that the "root privileges" part of this process is the reboot. Upon rebooting, system updates are applied from the new image via some privileged process.

That's pretty neat. Unfortunately I haven't ventured deeply enough into that type of system yet (was it called immutable distro or something?). I use gentoo, which doesn't support this out of the box.

Thanks for showing me something new!

Rebooting does not need root privileges either, on no system. There really is nothing privileged about updating already existing software. Android is completely rootless and updates are automatic, but can be done manually too.

You can read a bit into OSTree, its very cool. But seems to be very complex and somehow they want to switch to OCI images now, idk.

But the way ublue builds their systems is astonishing, elegant, simple, structured and fully automated.

What is the privileged action in pulling and applying updates your distro ships

Tell me again how you want to write system files with a non-admin account, and I'm going to show you my friend Lumpy, who will walk all over your machine so fucking fast. Fuck that, Lumpy's a genius. One of his underlings (he manages now) will do it on a lunch break.

From what I hear, doas is more secure. I don't think it matters though, as long as you keep your system updated. I use sudo still.

It's really only more secure in the sense that in general more complicated programs have more things that can go wrong with them. Either bugs, or just user error.

That is a valid concern, and most people don't need or use any of sudo's extra features, so it's completely reasonable to switch to doas because of that, but it's not like there's some glaring security flaw in sudo that most people really need to worry about. Especially if they're not doing weird things in the config, which would mostly be the same people who could easily switch to doas anyway.

How is it more secure?

Afaik much smaller code base and as such easier to audit.

I think it's because sudo only requires a password the first time on each shell.

It's entirely configurable but I think by default sudo will "cache" your authentication for a period of time so multiple commands in the same session only need the password entered once. You can even configure sudo to not need a password for certain commands (although obviously you need to be careful you're not opening a hole in your security).

doas is likewise configurable; though the mechanism that keeps track of the timeout is different on OpenBSD (where doas originated) & Linux ---- and there used to be some reservations about the latter implementation.

Doas has about 90% of features with 10% of code size of sudo.

And rdo/ssu have ~140 lines of C code. Anyone knows similiar?

Well, i believe in all showcased cases from people here, they are NOT replacing sudo entirely (Except if some are from BSD or if I'm incorrect with this assumption). They are just replacing their user habit with doas and use that command instead. In the end, all unix scripts or apps expect using sudo (If not, su) so... ### What's even the need to ?

  • Size : Installed on top of the already system present sudo.
  • Security : Only perhaps if you made a sudo alias to doas (But since it isn't entirely 1:1 identical, if anyone have a cleaner way of implementing that, I'm all hear)
  • Simplicity : You now have two tools. A easy to use keycard, and a key. The second is more complicated to use, so you use it rarely but it's still two tools instead of one.
  • Less dependencies : Again, unless you can actually replace it ENTIRELY, it's just an added tool (Still almost dependency free)

Really looking to corrections if i do some

doas uses like 10MIB less of mem than sudo.

What's the point of using MiB if you're just gonna say "like" lol

Because it is not exactly 10MiB. Should have used about instead of like though.

I mean just say MB if you're not being exact

MiB and MB are not the same thing. Just that many CLI tools in linux use MiB instead so I just got used to typing MiB lol.

The difference between MB and MiB is 24 kilobytes

My point is that if you're already estimating, the difference is negligible

24 kibibytes. I dislike the annoying difference between kiB and kB, etc, etc as I also think in kB and MB as the binary values because that's how I was taught for many years.

Again. If you're not being accurate then theres no point jn being precise

You're replying to the wrong person. I added some info over the difference between your comment and someone else's acktually comment.

I don't care either way; an approximation in MiB and MB is the same difference to me. The other person and yourself have got into a debate about nothing in my opinion.

Security may be more likely to approve some users having doas, sudo is a no go in many restricted environment.