# sudo or doas



## Geezer (Nov 4, 2021)

How do you run as root, sudo or doas?


----------



## SirDice (Nov 4, 2021)

Still old-school sudo(8) (and sometimes su(1)). And I'll probably keep using it because it's used at all places I work too.


----------



## eternal_noob (Nov 4, 2021)

Neither. I see `sudo` or `doas` as a security risk.
What's wrong with temporarily becoming root via `su -`, do the work and `CTRL + d` back to the user?


----------



## Erichans (Nov 4, 2021)

Being a little provocative , perhaps also interesting the option:
- do not login as root and _do_ care; for example use `su` instead.


----------



## SirDice (Nov 4, 2021)

eternal_noob said:


> What's wrong with temporarily becoming root via `su -`, do the work and `CTRL +d` back to the user?


Problematic if you have to delegate certain tasks to other people. Then you have to give them the root password, which you don't want to do in a larger organization. We have application maintainers, they can stop/start and reconfigure the application service they maintain. You don't want to have to give them the root password.


----------



## eternal_noob (Nov 4, 2021)

I can't see which tasks that would be.

Edit files? Edit them in your f*cking $HOME, root copies them later.
Install software? Forget it, only root does it.
View logfiles? Add a dedicated group and change permissions

Edit: Ok, the reason you edited in makes sense (until i can think of a better solution).


----------



## SirDice (Nov 4, 2021)

eternal_noob said:


> I can't see which tasks that would be.
> 
> Edit files? Edit them in your f*cking $HOME, root copies them later.
> Install software? Forget it, only root does it.
> View logfiles? Add a dedicated group and change permissions


Try maintaining 900+ servers running a myriad of different software. We maintain the platform, other specialized teams maintain the software.


----------



## a6h (Nov 4, 2021)

I like doas(1) much better. doas.conf(5) is simple, I understand it thoroughly.
On logging as the root, and `su -`: rarely, only if it is absolutely necessary.


----------



## _martin (Nov 4, 2021)

As root, and I do care.


----------



## Jose (Nov 4, 2021)

I recently switched to doas because sudo has become bloaty and is starting to have security problems. The lack of `persist` on Freebsd is really kind of a killer, though and I'll probably switch back.

Why not `su -`? Because I don't like interactive sessions as root. I don't want to get used to it. Having to type "sudo" or "doas" is just enough friction to make me think about what I'm going to do for a fraction of a second longer. Sometimes that makes all the difference.

I do wish it was easier (or even possible!) to build ports as an unprivileged user. I work around this by building everything in a jail, but that adds a little too much friction. I like the peace of mind of knowing that my user account simply can't write to most places in my filesystems. That's one of the killer features of Unix-like operating systems.


----------



## George (Nov 4, 2021)

They have a different design. In a terminal, I use sudo. It's more flexible, and password based. In scripts, I like doas more.


----------



## SirDice (Nov 4, 2021)

eternal_noob said:


> Edit: Ok, the reason you edited in makes sense (until i can think of a better solution).


There are certainly better solutions to think of. I've suggested a couple already, but those application maintainers typically don't want to change the way they've been working for the past decade or so. So it's very difficult to actually get some of that implemented. Will need to take baby steps and a lot of negotiation in order to change anything.


----------



## Vull (Nov 4, 2021)

I use `su` via `ssh` or a desktop terminal logged in as a lower level user, so I checked the 3rd option.

Partly out of old crusty habits, and partly because I've never worked out of any shop which had over 10 programmers.


----------



## shkhln (Nov 4, 2021)

Jose said:


> I do wish it was easier (or even possible!) to build ports as an unprivileged user.


Weird. That works just fine already and, in fact, is explicitly supported: https://github.com/freebsd/freebsd-...0c0f93a6313f874decc1c9e99/CHANGES#L1709-L1720.


----------



## dbdemon (Nov 4, 2021)

I _want to_ use doas, but I think with the lack of `persist` makes it too impractical. 

I'm used to sudo from working with Linux, and use that extensively in my job. I suppose I'm in that application maintainer category that was mentioned above. Our sysadmins also use sudo themselves.


----------



## Jose (Nov 4, 2021)

shkhln said:


> Weird. That works just fine already and, in fact, is explicitly supported: https://github.com/freebsd/freebsd-...0c0f93a6313f874decc1c9e99/CHANGES#L1709-L1720.


Didn't work the last time I tried, and spent a lot of time chasing my own tail setting environment variables that had little or no effect. There isn't a single place where the process and all the variables involved are documented. That changelog implies there are ports that can't be built without root ("NEED_ROOT"). It looks like the only way to find out is to grep all the makefiles.

It's possible it works now, but I'm not going to be the first one to figure it out.


----------



## zirias@ (Nov 4, 2021)

I use `su`. I see there are usecases for these tools (selectively allowing who can execute what as super-user), but as the only operator in my private network, I don't need that. And on the plus side, if my password is ever compromised, there's still the root password


----------



## Beastie7 (Nov 4, 2021)

Mr. Salty said:


> We're around 30,000 Linux servers and 1,000 Linux workstations, but that does not include thousands of containers spun up for Java, or Windows which I'd approximate to be about 2,000 servers (not Windows workstations which would be several thousand).



This is folklore. Stop it.


----------



## xtaz (Nov 4, 2021)

I have a few sudo rules where the command is something like "/sbin/pfctl -t blocks -T *" where the * acts as a wildcard for any further arguments after the command. doas can't do that so it's useless for me. Shame really as I also dislike sudo.

What I mostly do though is have one window in my tmux session called root which has a permanent "su -" in it.


----------



## SirDice (Nov 4, 2021)

Mr. Salty said:


> We're around 30,000 Linux servers and 1,000 Linux workstations, but that does not include thousands of containers spun up for Java, or Windows which I'd approximate to be about 2,000 servers (not Windows workstations which would be several thousand).


And I presume you're not giving out the root password for all those server to various other teams or groups of people either. I'm quite sure you have something in place for that.

When you're a small team managing a handful of servers it might be fine to share the root password when needed, and just stick to su(1). When teams and environments get larger you need to start delegating tasks to other teams. I've been to places that were very much in a transitional phase from small to medium sized and it's just simple to use sudo(8) to root and let them handle it. The place I'm currently employed is more in a medium to large transition. We don't allow blank sudo(8), if you require access to certain services you only get to touch those services and nothing more. We have a large selection of rules, and puppet makes sure the correct rules for that server (and application) are applied. Even getting on to the servers is also very restricted. There are still plenty of improvements to make, and a recent piss poor performance on a pentest showed them they were doing it wrong for too long (most of that misery pertains to windows systems, more correctly, the people that maintained those windows servers). So they're now trying to shore up their security (and procedures). I'm going to take that as an opportunity to introduce more drastic improvements. Strike while the iron is hot.


----------



## gpw928 (Nov 4, 2021)

SirDice said:


> Try maintaining 900+ servers running a myriad of different software. We maintain the platform, other specialized teams maintain the software.



Indeed.  Depending on your circumstances, there may be a multitude of teams with a stake in the management of your systems.  These might  include:

the Unix Support team (who do the Unix work);
the Operating System Monitoring team (who look for Unix-related problems, 24x7);
the Gateway team (who manage the nexus to the Internet);
the Developer team (who write the applications);
the Application Support team (who investigate application problems);
the Application Monitoring team (who look for application problems, 24x7);
the Transaction Monitoring team (end-to-end instrumentation of all transactions);
the Database team (which is just another kind of application);
the Internal Security team (who watch everyone, including the other watchers);
the Log Management team (central collection, and analysis of logs);
the SAN management team (who look after all the storage);
the Network team (who direct the electrons);
the Project Management team (who organise and direct multi-disciplinary activities); and
the Quality Assurance team who co-ordinate all the other teams.
I have worked in places where most of these teams were present, and separately constituted.

Changes to production systems are going to be rigidly controlled.  But there still has to be mechanisms for application support people to perform their routine work requiring elevated privilege (e.g. application start, stop, and software release).

The development, test, and hot-fix environments would all require privilege escalations to get a wide range of routine work done by developer, application support, and test teams.

In a security-minded environment, you have to trust the Unix administrators to some extent (`su` still gets logged), but for everyone else, all routine privilege escalations would be controlled by `sudo` (or similar), logged, and analysed automatically for any sign of problems.  In these situations the log management team is generally held at length (and often physically separated in a secure situation).  All non-routine changes would be raised, approved, and passed, via some formal work management system, to the team(s) with the required authorisations.

And, `su -` by anyone outside Unix support is is *most certainly* a clear sign of malfeasance...  It would attract a lot of attention...


----------



## Geezer (Nov 5, 2021)

Mr. Salty said:


> We're around 30,000 Linux servers and 1,000 Linux workstations, but that does not include thousands of containers spun up for Java, or Windows which I'd approximate to be about 2,000 servers (not Windows workstations which would be several thousand).


Yes, yes. I've got a billion servers.

But what do you use, sudo or doas?


----------



## a6h (Nov 5, 2021)

Geezer said:


> Yes, yes. I've got a billion servers.


Billion with 10^9 zeros or 10^12?


----------



## ralphbsz (Nov 5, 2021)

dbdemon said:


> I'm used to sudo from working with Linux, ...


You can install doas on Linux. I have it on my Raspbian machines.


----------



## vermaden (Nov 5, 2021)

On some systems I installed both because when *sudo(8)* was killed because or 'wrong' <*/usr/local*>*/etc/sudoers* then you could use *doas(1) *to fix it


----------



## rotor (Nov 5, 2021)

vigole said:


> I like doas(1) much better. doas.conf(5) is simple, I understand it thoroughly.



That is the reason why I switched.  doas.conf(5) is straightforward.  I can config what I need quickly, without getting lost in the docs.


----------



## drhowarddrfine (Nov 5, 2021)

Beastie7 said:


> This is folklore. Stop it.


There's a different, better word than folklore for his statement.


----------



## ayleid96 (Nov 5, 2021)

I never used sudo.. It isn't logical to me personally. If i want need root privileges i login as root and that's it. If person makes mistakes it will make both with sudo or su it doesn't matter.

With great power comes great responsibility and there is nothing to protect you from making mistakes.


----------



## forquare (Nov 6, 2021)

SirDice said:


> Try maintaining 900+ servers running a myriad of different software. We maintain the platform, other specialized teams maintain the software.


I've worked in one organisation that was this sort of size, and I hated that we never configured security/sudo properly.  Any developer was allowed to have _full root access_ via the sudo command 
The basic conversation would go:

Dev:  We need to be able to run commands as root
Me: OK, what commands? 
Dev: Oh I don't know, many commands - hey PM, this guy is wasting my time and blocking the project
PM: <talks to relevant parties, authorises Dev to have unfettered access>

I suppose the caveat to this story is that the access _should_ have been removed before the servers went into production.  That wasn't my responsibility in that organisation, but I suspect it wasn't revoked...

For my personal FreeBSD machines.  I use plain su(1), and of course I take care!  On Linux machines I will use sudo.

At work today, no one really gets root access.  You make a change in source control, relevant people review the change, it gets deployed to a staging environment and tested, then rolled out to production.  Anyone can make the change, only key people can review, merge, and promote it.


----------



## gpw928 (Nov 6, 2021)

forquare said:


> Any developer was allowed to have _full root access_ via the sudo command


Wow!  How can you take responsibility when you have no control?  Your managers were incompetent.

I have never worked in a place where that would have been allowed.

These days, developers can have their "own" VMs on their desktop, but test and production systems need to be nailed down.  Tight.

Any changes required by developers to test or production environments must be documented and subject to formal change request or incorporated into the written release or hot fix procedures (which are generally just another type of change request)..


forquare said:


> At work today, no one really gets root access.  You make a change in source control, relevant people review the change, it gets deployed to a staging environment and tested, then rolled out to production.  Anyone can make the change, only key people can review, merge, and promote it.


That's true for routine deployments, but you still need to deal with full file systems, network maladies, "hardware" re-configurations, SAN/storage changes, runaway processes, OOM events, wedged systems, unexplained phenomena,...


----------



## astyle (Nov 6, 2021)

So, this is the thread that Mr. Salty got so upset about... Yeah, that was childish.

As for me, I use `su` to do my work, and then `exit` when I'm done. I tried using `sudo` in college - never got used to it. I only use `su` when it's just unavoidable - otherwise, I just work as regular user.


----------



## astyle (Nov 6, 2021)

forquare said:


> Dev: We need to be able to run commands as root
> Me: OK, what commands?
> Dev: Oh I don't know, many commands - hey PM, this guy is wasting my time and blocking the project
> PM: <talks to relevant parties, authorises Dev to have unfettered access>
> ...


 A common pattern. I was sideswiped at my place, too.  Although, in my case, it was PM not understanding how firewalls work on the network.


----------



## Beastie7 (Nov 6, 2021)

drhowarddrfine said:


> There's a different, better word than folklore for his statement.



Lol


----------



## dbdemon (Nov 6, 2021)

forquare said:


> Dev: We need to be able to run commands as root
> Me: OK, what commands?
> Dev: Oh I don't know, many commands -


I'm guilty of this  But honestly, it can be very hard to enumerate all the possible commands you might need for properly supporting certain systems. We have managed to work out a reasonable list of commands for the production system at least.


----------



## Jose (Nov 6, 2021)

forquare said:


> Dev:  We need to be able to run commands as root
> Me: OK, what commands?
> Dev: Oh I don't know, many commands - hey PM, this guy is wasting my time and blocking the project
> PM: <talks to relevant parties, authorises Dev to have unfettered access>


And then it was the PM's ass on the line when there was that massive data breach that cost the company millions in lawsuits and lost revenue, right? (Yeah. That's sarcasm.)



dbdemon said:


> I'm guilty of this  But honestly, it can be very hard to enumerate all the possible commands you might need for properly supporting certain systems. We have managed to work out a reasonable list of commands for the production system at least.


Never had a need in 25 years. I still sometimes get root despite my best efforts, usually because sysops wants my help.


----------



## rotor (Nov 6, 2021)

forquare said:


> PM: <talks to relevant parties, authorises Dev to have unfettered access>



That is a good illustration of what I used to say when I managed a large development team...

~The organization of the team determines the organization of the resulting software.~

In the case you cite, the team was not organized such that security was important, so the resulting software had poor security.


----------



## astyle (Nov 6, 2021)

Jose said:


> And then it was the PM's ass on the line when there was that massive data breach that cost the company millions in lawsuits and lost revenue, right?


At least it won't be yours.


----------



## fluca1978 (Nov 7, 2021)

I was a `sudo` fan, then I discovered `doas` and I like the idea. However, I tend to install both because my fingers are often used to type the wrong command and other users are not used to `doas[(/cmd] and, sometimes, don't understand the change.`


----------



## a6h (Nov 7, 2021)

Some notes:

Note I:
Until few days ago, I thought "doas" is pronounced "do-as", i.e. do (run) as [user X]. It turned out "doas" stands for "Dedicated OpenBSD Application Aubexecutor".

Note II:
Using "permit" is superior to "deny". It prevents to bypass the rule, via changing the path and/or name of the command.


----------



## rotor (Nov 7, 2021)

vigole said:


> It turned out "doas" stands for



circa 2015:






						doas - dedicated openbsd application subexecutor
					






					flak.tedunangst.com


----------



## Erichans (Nov 7, 2021)

vigole said:


> Some notes:
> 
> Note I:
> Until few days ago, I thought "doas" is pronounced "do-as", i.e. do (run) as [user X]. It turned out "doas" stands for "Dedicated OpenBSD Application Aubexecutor".
> ...



The inventor of doas(1) is Ted Unangst (for example see: Developing Software in a Hostile Environment by Ted Unangst). I don't have a pronunciation example of doas by him. Closer to home: I have tracked down an example by Benedict Reuschling & Allan Jude: BSD Now, Episode 305 (Changing face of Unix) starting at around 47:47 min (doas environmental security) where it is pronounced as "do-as".  Don't know anything about the "do (run) as [user X]" part though.

On his website Ted Unangst writes here:


> doas - dedicated openbsd application subexecutor



He also has a mastery-page:


> So here is the official *doas mastery* book. Or pamphlet, anyway.


where you can find all about permit & deny.

So, treading lightly, I conclude that your stated contradiction, "I thought [...]" versus "it turned out [...]" is not there; at least in part.
​


----------



## bsduck (Nov 7, 2021)

vigole said:


> Until few days ago, I thought "doas" is pronounced "do-as", i.e. do (run) as [user X]. It turned out "doas" stands for "Dedicated OpenBSD Application Aubexecutor".


The one doesn't make the other wrong, it was probably meant to stand for both at the same time


----------



## Jose (Nov 8, 2021)

vigole said:


> Note I:
> Until few days ago, I thought "doas" is pronounced "do-as", i.e. do (run) as [user X]. It turned out "doas" stands for "Dedicated OpenBSD Application Aubexecutor".


I'd take that with a grain of salt. Tedu@ has a sense of humour:


			'systemd compat for doas' - MARC


----------



## a6h (Nov 8, 2021)

Jose said:


> I'd take that with a grain of salt. Tedu@ has a sense of humour:


Fortunately, over there, having a sense of humour is still a feature. The last two paragraphs: KARL - kernel address randomized link


----------



## a6h (Nov 8, 2021)

Erichans said:


> The inventor of doas(1) is Ted Unangst (for example see: Developing Software in a Hostile Environment by Ted Unangst). I don't have a pronunciation example of doas by him. Closer to home: I have tracked down an example by Benedict Reuschling & Allan Jude: BSD Now, Episode 305 (Changing face of Unix) starting at around 47:47 min (doas environmental security) where it is pronounced as "do-as". Don't know anything about the "do (run) as [user X]" part though.


Thanks for detailed explanation of the matter. 47:47, nice timecode! I don't follow that podcast, so I'll take your word for it, and call it do as, as is.


----------



## Jose (Nov 8, 2021)

vigole said:


> Fortunately, over there, having a sense of humour is still a feature. The last two paragraphs: KARL - kernel address randomized link


That's the dark humour.


----------



## astyle (Nov 8, 2021)

Jose said:


> That's the dark humour.


not as dark as `# /bin/kill -9`...


----------



## rafael_grether (Jan 31, 2022)

Well, I've always used sudo on Linux, so for convenience I ended up using it on FreeBSD as well.

BUT due to a recent security issue in sudo (CVE-2019-14287) that was widely exploited in the wild, and the proof of concept only requires a simple command line, I decided to replace it with DOAS.

In my organization, DOAS is sufficient, and meets all my needs.

SUDO has been the focus of hackers trying to find vulnerabilities, and like this last, others can be found too.

DOAS is not largely used like SUDO, thus, it ends up not being the focus of hackers (at least so far).
And since it is simpler, it reduces exploration vectors.

Thus, I have now adopted DOAS in my organization.


----------



## SirDice (Jan 31, 2022)

rafael_grether said:


> DOAS is not largely used like SUDO, thus, it ends up not being the focus of hackers (at least so far).


Which also means there could still be lots of security issues hiding that just haven't been found yet because it doesn't get the same attention. Absence of evidence is not the same as evidence of absence.


----------



## Erichans (Jan 31, 2022)

SirDice said:


> Which also means there could still be lots of security issues hiding that just haven't been found yet because it doesn't get the same attention. Absence of evidence is not the same as evidence of absence.


I agree. By the same reasoning however, one could assert the reverse: "software" (as part of an OS that is dominant all over the planet) is therefore "likely to have less security issues" because it has such a large attack vector that (dormant) security issues surely must all have come up ( ... and will have been mitigated quickly ... ). I know this may not be an apples to apples comparison but I can think of one particular OS.

What attracts me in doas over sudo is in the first place that it offers less* and because of that, it is less complicated; it is also smaller (LOC). Both lead me to believe: it is easier to maintain. doas(1) is also the OpenBSD sanctioned variety of sudo as part of its base install.  As far as security reliability is concerned, I think it is therefore reasonable to assume that it is at least on par with sudo. Because it is less complex, it may be less likely for a user/sysadmin to make mistakes in setting up and maintaning access control. All are somewhat subjective qualifications, I know.

___
* I have no idea what the tipping point might be when in need for a more fine grained and complex control, as may be the case in larger organisations.


----------



## rafael_grether (Jan 31, 2022)

Good point, Sir Dice! 
You're right!

When OpenBSD 5.8 was released, was announced the replacement of sudo by doas.
Because it is much simpler, minimalistic. But nothing was said about security.

But OpenBSD is "paranoid" about security, so I don't think there's any reason for me to worry about that.

In fact, I never had to use all complexities of sudo. For the web manager, permissions to manipulate apache/php services, and so on.


----------



## drhowarddrfine (Feb 1, 2022)

rafael_grether said:


> due to a recent security issue in sudo (CVE-2019-14287) that was widely exploited in the wild, and the proof of concept only requires a simple command line



Isn't that like a three-year old issue that was fixed even then?


----------



## grahamperrin@ (Feb 1, 2022)

_☑ something else (what)_

Three things:

Control-Alt-F2, `ttyv1` login as _root_, switch to my desktop environment with Alt-F9, to-and-fro between the two
`su -`
`sudo ⋯`
Superuser aside, I sometimes also `ttyv4` login as _grahamperrin_ without a desktop environment, then again to-and-fro. `ttyv4` because F5 and F9 are nicely separated on the type of extended keyboard that I most often use. So, it's like:

index finger = my console
little finger = my desktop environment
– without looking at the keyboard.



Geezer said:


> Yes, yes. I've got a billion servers.



All running FreeBSD, of course. Then, put a desktop environment on just one of them, and be _told_ that you're hindering development of a server-only operating system.


----------



## drr (Feb 1, 2022)

I voted 'something else (what)'.

I use `su -` to become root whenever needed. I have used `sudo` a lot in the past, in my linux days, but now I have got used to using `su -`. I have not used `doas` so far; I will give it a try someday.


----------



## hruodr (Feb 1, 2022)

BTW, I do normally su, but in the meantime I use doas for typing some commands, 
but only for doing things faster, it is not a principle. Doas and not sudo because 
it is easier to configure, I never saw the need of these commands.


----------



## dbdemon (Feb 3, 2022)

For my own very modest requirements I think `su` is sufficient.


----------



## john_rambo (Feb 3, 2022)

I had used doas under OpenBSD. Before reading this thread I had the wrong idea that doas belongs to OpenBSD. I use sudo under both FreeBSD & Linux.


----------



## ralphbsz (Feb 3, 2022)

john_rambo said:


> Before reading this thread I had the wrong idea that doas belongs to OpenBSD.


It does. Doas was developed in OpenBSD, and first used there. It has since been ported to other OSes; I use it on FreeBSD and on (Raspberry Pi) Linux. One of its important features only works in OpenBSD, namely remembering for 5 minutes that the user has entered their password.

Why do I use doas? Mostly because the config file is simple, yet expressive. I can adjust "who can do what" easily and intuitively.


----------

