sudo or doas

[rotor]

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]

This is folklore. Stop it.

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

 

[ayleid96]

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]

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]

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

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]

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]

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

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]

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

Lol

 

[dbdemon]

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]

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

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]

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]

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]

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]

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]

It turned out "doas" stands for

circa 2015:

doas - dedicated openbsd application subexecutor

flak.tedunangst.com

 

[Erichans]

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.

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]

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]

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]

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]

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]

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]

That's the dark humour.

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

 

[rafael_grether]

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]

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]

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.