Tracy R Reed wrote:
Good stuff:
http://cr.yp.to/qmail/qmailsec-20071101.pdf
One of the most interesting arguments he makes in this paper is that we
should not be using relatively low level languages like C to write
things like mail servers. He says security is much more important than
speed. I agree. Especially for things like qmail/sendmail which spend
the vast majority of their time waiting on IO instead of waiting on cpu.
He does say least privilege is not as important as we think. I tend to
disagree with that. The example he cites is one case where least
privilege doesn't help that much but in many other cases it is critical.
I am envious of George Guninski for having found a bug in djb's code
(although not a security bug).
He says: "Most programming environments are meta-engineered to make
typical software easier to write. They should instead be meta-engineered
to make incorrect software harder to write." I like this. This is part
of what appeals to me about functional programming, lack of state, and
type enforcement like Haskell has. I'm not saying these ideas solve the
problems they claim to (although I am optimistic) but I do like the idea
that someone is even paying attention to these things.
DJB uses testing to check that all of his code works as expected and
continues to work as he makes changes. I need to start doing this. The
Plone guys are big on this also. Zope/Plone has astonishing unit test
coverage. At the end of section 3.4 he says that testing the code would
have been much easier if it had been written in purely functional style.
This makes sense and supports my investigations into whether functional
programming improves code quality.
A lot of programmers don't like to interrupt the flow of their coding
and just write big long functions to get things done and then never go
back to refactor. In 4.1 he mentions factoring things out, especially
little utility functions, as a means of improving quality. I have known
certain perl programmers who hated to pull out just 4 lines of their
code into a standalone function.
I wonder if something like Erlang would be a good language to write a
mail server in. Email is a critical application which absolutely must be
running. Erlang handles errors in an interesting way. In a C program if
a fatal error happens the program can just exit/be killed. In section
4.2 he points out that this isn't a good idea for programs that are
supposed to be long running. But a standard Erlang way of dealing with
errors is that the program dies but then the interpreter/virtual machine
just restarts it. This could be better than trying to write a bunch of C
code to detect and prevent all manner of errors. DJB says he probably
should have written it in another language and then translated it to C
for distribution. But I don't see how this is any better than just
distributing some other high level language which has interpreters for
pretty much all common platforms.
He makes good points about using the operating systems network tools,
access tools, database tools (filesystem) etc. and makes some very good
points which reduce the amount of potentially buggy code.
Section 5.2 makes a good point and basically uses a functional
programming idea to sandbox calculations such as rendering a jpg into a
bitmap avoiding potential exploits caused by malicious data. Expensive
to do in a Unix style process but perhaps not so bad in a sandboxed
thread in a virtual machine like Erlang or Java.
Overall a very interesting paper. It is fun to see DJB actually humble
himself a bit and admit to errors made in the initial Qmail design and
suggest fixes. Qmail is still an amazing accomplishment due to having
the complex functionality of an MTA while pretty much zero bugs over the
last 10 years. I really can't name another project with such a track record.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg