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

Reply via email to