
Doas – Dedicated OpenBSD application subexecutor - ingve
http://www.tedunangst.com/flak/post/doas
======
ghshephard
Compare the code in doas: [http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/doas/](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/doas/) to the epic beast that was sudo:
[http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/sudo/](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/sudo/)

Amazingly - for such a tiny bit of code, it still has 100% of the
functionality I've ever used with sudo: [http://www.openbsd.org/cgi-
bin/man.cgi/OpenBSD-current/man5/...](http://www.openbsd.org/cgi-
bin/man.cgi/OpenBSD-current/man5/doas.conf.5?query=doas%2econf&sec=5)

And you just have to love a man page like this:

[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man1/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man1/doas.1?query=doas)

I really, really like the direction OpenBSD is going. Bit by bit the base
operating system is becoming a leaner animal, rid of a lot of cruft that has
the potential to bite people in the future.

And, note - for anyone who is wondering how one can get by without sudo for
backwards compatibility - sudo isn't going away, it's just being moved out of
base into ports. If you want to install it in your system - it's just a
pkg_add away.

~~~
danieldk
_to the epic beast that was sudo:_

I don't want to defend sudo, but by definition any C utility that is multi-
platform is going to be larger. Also, sudo has features that are required in
some enviroments, like LDAP or PAM support.

I definitely agree that the direction they are going in is great: a lean base
system that has as little attack surface as possible and covers 95% of the use
cases. If you do need extra functionality, get it from ports.

One thing I wonder about though is: why does a system which goal is security
still use C for utilities/programs that are not really CPU-bound? Maybe it's
time to slowly ditch C for a safer language where possible? (There are
languages that would fit in quite well with OpenBSD, except that they require
some portability work.)

~~~
DominikD
Most systems developers are proficient with C. Code isn't going to be safer in
language XYZ if developer isn't proficient with it, no matter how awesome XYZ
is. This also ties into the legacy: there's a lot of code in C out there that
you can't simply replace. Also keep in mind that most of the "safe" languages
depend on runtime which isn't written in a safe language. So you're just
pushing the problem somewhere else.

Even pretty bare metal languages like Rust aren't very well suited for OS
development (yet) since they come with certain assumptions about memory
subsystem. Which has to be implemented to be used. This is also true for C -
there's some stuff in every C standard library that has to be written in asm,
once for each supported platform.

So the bottom line is: there's always something underneath. You can get to a
safer place by minimizing these pieces of "unsafe" code and writing code in
something else above or, what OpenBSD does, you can abstract and isolate
things away and use the tiniest possible solution for each problem and achieve
safer environment by proper separation of concerns.

~~~
danieldk
_Code isn 't going to be safer in language XYZ if developer isn't proficient
with it, no matter how awesome XYZ is._

There are safe languages that are similar enough to C that it is not hard to
pick them up for a C programmer. I agree if the replacement is ML or Haskell.
But e.g. Rust, Cyclone, or Go (if a GC is acceptable) are not going to be hard
for most C programmers.

 _Also keep in mind that most of the "safe" languages depend on runtime which
isn't written in a safe language._

Rust is almost runtime-less. The Go runtime is mostly Go since 1.4.

 _This is also true for C - there 's some stuff in every C standard library
that has to be written in asm, once for each supported platform._

I didn't say it's not going to be work :).

 _So you 're just pushing the problem somewhere else. [...] So the bottom line
is: there's always something underneath._

That does not mean that, say, Haskell is not tremendously much safer than C.
First, because you only have to implement the icky parts once. Second, because
a better type system and abolishment of undefined behaviour gives you more
safety for a very small cost (if at all, the extra compile time for a better
type system is probably negated by the cost of headers).

~~~
aninteger
zamalek got it correct above. Those languages above only cover 2 or 3
architectures that the project works with. There is no Rust or Go compiler for
vax, alpha, macppc, sparc64. There are C/C++ compilers though.

~~~
danieldk
Yes, I know, that's what I mentioned in my original post: it requires
portability work.

 _There is no Rust or Go compiler for vax, alpha, macppc, sparc64. There are C
/C++ compilers though._

Well, I think compilers for some of these architectures (e.g. VAX and Alpha)
still exist in gcc largely because OpenBSD and NetBSD have put so much effort
in keeping them alive (yes, I know that OpenBSD is using an older version).
So, it's not as if you get C compilers for these platforms for free.

------
gnoway
This tool exec's, and its return status reflects whether the command could be
launched. Sudo waits and returns the exit code of the process. I'm surprised
this wasn't mentioned in the blog post, it's probably the most important
difference.

~~~
caf
If the exec is successful, it will be _replaced_ by the exec'd program, and
its exit code will then be whatever the exit code of that is.

------
leni536
Does anybody can use sudo in a way that it adds additional but limited
privileges to certain user groups securely? I'm sure it's used only for giving
admin privileges to the admin group 99% of the time. If your OS needs a tool
that allows users to run processes as another user then maybe your OS needs
finer access controls instead.

And for the 99% use case I think a few lines long C code would suffice.

~~~
ghshephard
sudo (at least everywhere I've used it) - is typically used to (A) allow me to
run code as root without having to type my password, and (B) give select
groups of people the rights to run a few specific commands. In terms of
number-of-time executed, in a recent environment that I was in, in which
approximately 100 or so people had sudo rights, 90+% of the time it was to
allow people in various group to run commands like "tcpdump" or "netstat",
without giving them full root rights to the system.

