Doas – Dedicated OpenBSD application subexecutor
tedunangst.com
tedunangst.com
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/...
And you just have to love a man page like this:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
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.
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.)
I think it has something to do with compiler ubiquity.
Let's use Python as a good example of "get shit done if you don't care too much about perf." The source tarball for Python is 18MB - even the Windows binaries are 25MB. TCC[1] is 100KB. We can use that as a bad estimate of how hard the platform/runtime is to port.
Let's say you wanted to get Doas working on some pet Unix OS that you are writing. If it was written in Python you'd have to first get the entirety (25MB) of Python working; if it was written in C you'd simply cross-compile as you would be already doing for everything else. I'd put good money on you wanting to get Doas/Sudo working before you get Python working or the bajillion different runtimes that all the utils are written in.
In that way C has this very peculiar portability: it's not write-once-run-everywhere but it can be write-once-compile-everywhere. It's a common denominator.
I could be completely wrong and it could just come down to: old habits die hard.
I'd be interesting in knowing what their thinking is as well. If I had to totally guess - it would be that the OpenBSD team has 15+ years of world-class expertise in writing safe/secure C code, and that switching to a different language would (A) mean having to learn how to do this all over in another language (albeit in a much, much easier manner) and (B) dealing with the abstractions that a language might bring, that didn't exist when you were writing in C.
Presumably the advantages of having a memory safe language don't have the benefits for the OpenBSD team that outweigh the negatives. Yet. I guess time will tell.
On the other hand, MirageOS has no hardware drivers and depends entirely on a Xen hypervisor. This may be a smart move to get it all going, but also means a fundamental dependency on yet another large piece of unsafe code.
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.
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).
Rust is a very large language with an equally large set of standard library functions. It also requires changing how you structure your programs to work within the constraints of the borrow checker.
Rust also relies on LLVM, which has a limited set of target architectures when compared to C.
It's a much better replacement for C++ than C.
(Also, not really advocating the use of Go to replace C in operating system development, just wanted to make a note)
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.
It's not about similarity, it's about differences. System code is all about subtleties in language, UBs in C for example. Just because Rust syntax is similar doesn't mean it can be easily picked up by a C dev.
"Rust is almost runtime-less."
Almost is the key. Even FAQ mentions that it's not suitable for low level code exactly because of its assumptions about how memory allocator works. You'd have to implement it. And you still assume that compiler output is flawless (which is very unlikely given Rust's age).
"I didn't say it's not going to be work :)"
But that's exactly what you're implying ;P "Oh come on, it can be done, why not?!" I'm giving you reasons why. These aren't superficial, I worked on OS, OS drivers, I'm currently working on hardware simulators. If your aim is safer systems, switching from C to Rust (which I happen to love) isn't the answer yet. And probably not for the next 10+ years.
"That does not mean that, say, Haskell is not tremendously much safer than C."
I'm not saying that there are no languages inherently safer than C. I'm saying that a) people can't switch just like that, b) familiar syntax isn't enough, c) legacy matters, d) there's always something that will still be "unsafe". As a pragmatic I'm claiming that you can spend time better than switching languages.
"First, because you only have to implement the icky parts once."
How is this not true in C?
"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)."
No, again, cost associated with new language is massive, especially if you care about quality.
I'm curious as to what you're referring to here, with Rust. Could you elaborate?
My feeling though is that you need to be able to allocate memory to write code in Rust (duh!) and memory allocation is something that OS provides. So if you write OS in Rust... you get the idea. My understanding of Rust isn't deep enough to state whether you'd have to reimplement internals of Arc, Box and what not or you'd just have to provide something they piggy back on. But there's an explicit assumption in most of the code that you can allocate memory (in a thread safe fashion no less) which isn't there if you have no OS underneath.
That interface is super unstable at the moment, and we're working on stabilizing it, but yeah, that's what you'd have to do: write your own allocator and hook it up.
We do use gcc's unwinding library, last I recall, but if you're writing an OS, you can implement the language items to do whatever you want, including just abort.
There's no inherent TLS implementation that I'm aware of.
(If you're arguing that drivers will still need some inline assembly, well, yeah. But the assembly required for hardware interop is pretty straightforward, at least compared to code written in assembly for performance).
I'm not saying it can't in principle, I'm saying it would take years to get to a usable point. But then again - I wouldn't mind being wrong here! :]
"I'd be interesting in knowing what their thinking is as well."
OpenBSD is proudly exploiting quirks of various platforms to stress test the code and find cases where differences break the code and expose bugs. Change from C won't happen just because Rust is here to stay. Especially not until LLVM (and preferably musl) runs on most of the platforms OpenBSD runs on. the official stance for LLVM in general is that it'd have to get to the parity with gcc WRT platforms that OpenBSD finds interesting but reality is that a platform or two out of ~15 could be dropped if LLVM provided benefits over gcc. LTS compiler is something OpenBSD (and not only them) would appreciate greatly. But it's not going to happen, I'm afraid.
OpenBSD's security goal (and expertise) comes from its programmers typically being really skilled at C programming. Some OpenBSD utilities use other languages, though (like the package management tools, which are written in Perl last I checked).
The bigger concern, however, is portability. OpenBSD supports a lot of hardware platforms, rivalled only by NetBSD as far as I know. There's also licensing restrictions; the goal is for OpenBSD (or at least as much as possible) to be entirely permissively-licensed. Any language that doesn't satisfy those two requirements may very well be a nonstarter.
And for the 99% use case I think a few lines long C code would suffice.
One example I've used was setting up some non-technical windows users with a shortcut they could click which would:
do a key-based, passwordless ssh login to the server rotate a proxy log, specific to their test machine
The logrotate config for these logs included code to move a copy to a mapped network share.
So clicking the shortcut caused the log for their most recent bout of testing to magically appear in a folder on their desktop.
The sudoers file allowed only this command to be run by these users. They did not get shell access at any stage.
backuppc ALL=(root) NOPASSWD: /usr/bin/rsync --server --sender ?*