SecurityFocus contributor Federico Biancuzzi chatted up Venema to talk about software security, how to improve the code quality, what solutions we might have to fight spam successfully, the principle of least privilege, and the philosophy behind the design of Postfix. Venema is currently a researcher at IBM's T.J. Watson Research Center.

SecurityFocus: Could you introduce yourself?

Wietse Venema: I had the good fortune to get my hands on the Internet when computer security was slowly becoming a concern, and I was able to make a few contributions with TCP Wrapper, Satan, Postfix, and The Coroner's Toolkit. Two of these, Satan and TCT, were done with Dan Farmer.

My background is physics, not computers. I learned to program defensively when writing the software that controlled my physics experiments. I was motivated to program very carefully, because these experiments ran round the clock for several weeks and I didn't want to live in the lab day and night. Once I acquired this programming skill, it was like riding a bicycle: you never forget how to do it.

When you released SATAN in 1995 it was marked as a controversial program, and even led SGI to fire your co-author Dan Farmer. Do you think the general point of view on security tools is changed since then?

It has certainly changed. Network scanning has become a standard tool, just like firewalls, intrusion detection, antivirus. Nowadays you can be considered negligent for not using these technologies.

In a perfect world, we would not need such tools because all systems would be completely free from errors, but we haven't reached that point yet. Modern Windows and Linux systems are already up to 50 to 100 million lines of code. Even good programmers have an error rate of one in 1000 lines, and with millions of lines of code being written each year, we're creating vulnerabilities faster than they can be eliminated.

There was a time when you were, as you said, "logging every network packet to disk. It's good insurance." Do you think such a public announcement might discourage some attackers nowadays?

Yes, but doing so deters only attackers who want to break into a specific site. Nowadays, most attacks are non-targeted. They don't care what machine they break into, and their packets are being logged all the time by honeypots and other sensors that collect data about attackers and malware. Full packet logging is also done by some network administrators -- with management approval of course -- but this requires a lot of storage resources.

On my own network, the resources are too limited for unselective packet logging. I am less concerned about non-targeted attacks anyway, and rely on a combination of measures to keep the place safe, including logging, least privilege, one-time passwords, network access control, and more.

Do you have a favorite method to reduce the number of vulnerabilities in software?

The earlier a defect is found, the better. I rely primarily on careful design and review, and secondarily on source code and run-time analysis tools. The best that program analysis tools can do in my experience is to transform programmers into better programmers, meaning you still have one error per 1000 lines of code.

I've mentioned in the past that programming should be a million times more difficult, so that fewer people would be able to write code. This is, however, not the direction where things are evolving. Instead, more and more people, with less and less experience, will be programming computer systems, and their programs will of course be connected to the Internet.

The challenge is to provide environments that allow non-experts to program computer systems without introducing gaping holes. Today, we're better at the first part than the second. For example, writing applications with PHP is comparatively easy, but it's harder to write PHP code without gaping security holes. I have done some work to improve this situation, but I don't expect miracles.

I expect more from radical changes in the programming model. Almost 30 years ago the spreadsheet's invention revolutionized the way that non-expert users could program their personal computers. Until then, those users were mostly stuck with BASIC. We need a similar revolution for programming the Internet.

What is your opinion on the current battle against spam?

Anti-spam tools alone will not solve the problem; they merely reduce the level of pain for the organizations and individuals that can afford the use of such tools. The technical arms race will continue unless politicians and law enforcement join the battle with effective measures that work across national borders.

In my personal opinion, the reliability of email reached its maximum near 1998; it has gone down ever since as the result of increasingly aggressive anti-spam/virus measures. This observation has led me to conclude that the spammers aren't destroying the email infrastructure, it's the well-meaning people with their countermeasures.

Is there any anti-spam technology that impressed you positively? Maybe Bayesian filtering?

Out-source it to human eyeballs. It's the best anti-spam technology to date. Humans can quickly recognize new patterns; computers need to be reprogrammed for each new trick that sidesteps the existing filter software. Of course these human eyeballs would still use conventional technology to filter out the obvious junk. By the way, spammers can out-source to human eyeballs too. For examples of this, type "captcha porn" into your favorite web search engine.

In practice, DNS-based IP address block lists will eliminate most spam for me: most Internet nodes should never send direct email across the Internet. Instead, they should send it through the ISP's mail servers, where acceptable use policies can be enforced. We already see this happening; spammers are already collecting user's ISP passwords and are using those accounts to send spam. Other spam can be blocked because of technical limitations in the way that zombies work, using techniques such as grey-listing, no-listing, and so on. All these techniques block email before it can be sent over the network, so they are relatively inexpensive.

I use email content inspection primarily to stop undeliverable spam that is being "returned" to me by poorly operated mail servers. These servers accept spam that claims to come "from me" for non-existent users at their site, and then later these servers send me unhelpful email that those users don't exist.

Do you think that the problem could be solved using a crypto based solution?

Authentication by itself does not make email spam-free, just like cryptography by itself doesn't make the Internet secure. Authentication provides a tool to confirm that mail from my bank actually came from my bank. However, authentication doesn't stop malicious parties from sending 100% authentic mail that comes from a bank with a very similar name, and that has a very similar website. For example, spammers were among the earliest adopters of SPF (sender permitted from) email authentication. They will adopt the authentication technology du jour without any difficulty.

What is the best theoretic solution to the problem from your point of view?

The best theoretic solution is to change the email distribution model, but this may never happen. Right now, email is a "push" technology where the sender has most of the control, and where the receiver bears most of the cost.

The alternative is to use a "pull" model, where the sender keeps the email message on their own server until the receiver downloads it. For example, when my bank wants to send me email, they would send a short message with an URL to view their mail, and my email software would download the message for me. This assumes of course that my email software recognizes my bank's email digital signature and their Web site's SSL certificate, otherwise we would have a phishing problem. Legacy mail software would tell the user that they have email at their bank, and leave it up to the user to download their email.

The "pull" model would change the economics of email. It would move the bulk of the cost from the receivers where it is now, to the senders where it belongs. No-one would read email if its sender doesn't provide a service where recipients can download it from.

And what is the best we can do concretely to improve the situation? Any suggestion?

Make it someone else's problem? Consider how much time is wasted dealing with SPAM and with its negative effects, convert that time into money, and see if you can afford having someone else do the filtering for you.

Some people use an anti-spam and anti-virus tool that interact with their MTA. Someone prefers to keep things separated, such as doing the filtering on a separated system, let's call it IPS, that filters various protocols (SMTP, HTTP, FTP, ...). What is your point of view on this type of filtering?

Our society has made progress because people have specialized. Some people bake bread, others make clothes, some build homes, some build roads, and so on. In principle, each of us could do all of those things, but the result would probably not be as good. I firmly believe that we will have better solutions when we use separate specialized building blocks, than when we try to build one system that tries to solve all problems.

What is your opinion on the principle of least privilege? "I have become convinced that this principle of least privilege is fundamentally wrong." This quote comes from a DJB's paper [PDF].

My opinion is that least privilege helps for some problems, but not for others. For example, when a mail system runs with a lower privilege level, an attack can do less damage to the host that runs the mail system. This was a big deal in the days that Sendmail was still running with full system privilege, and when it had several security vulnerabilities each year. However, least privilege does not help at all with attacks that cause the mail system to mis-handle email, such as delivery to the wrong people, loss of email, or corruption of content. You can limit the damage somewhat by partitioning the system into small isolated units, but the only thing that really helps is to avoid making mistakes that an attacker can exploit.

What philosophy (or principles or theories) inspired you when designing Postfix?

A lot of things went into the Postfix mail system. Some were already discussed in this interview. It would take a lot of time and space to discuss everything, so I will just mention a few.

At the conceptual level, Postfix has a very simple structure. It is built as a network router, with dedicated input interfaces, a central core, and dedicated output interfaces. The input interfaces strip off the protocol encapsulations of SMTP, QMQP, or UNIX text format, while receiving an email message. The central core manages the queue and decides what output interface to use for a given destination. Finally, the output interfaces each apply the appropriate encapsulations for SMTP, UNIX text format, or other, while delivering an email message.

This organization leads to a very natural decomposition into Postfix daemon processes that is good for security and that does not hurt performance. For example, each input or output interface becomes a separate daemon process, one per connection and interface type. The queue is managed by one daemon process, and then there are a bunch of little daemon processes that provide services to the other daemon processes, such as address rewriting, connection caching, or SSL session management. The whole lot is supervised by one master daemon process that spawns the other daemon processes on demand.

This organization into small processes also simplifies error handling tremendously, compared to mail systems that handle multiple simultaneous deliveries in one large process. All Postfix daemon processes except the master daemon process are disposable; if a process runs into a problem, it can die immediately, and the master will replace it. No mail is lost, and the rest of the mail system keeps working. It's like a tire that repairs small holes in itself without having to stop.

One lesson that I learned from this project is the need to provide safe extension interfaces. This allows sites to extend the mail system with specialized software that I don't want to write, like anti-spam/virus or digital signatures. This also extends the life of the software itself. Postfix does not have a tradition of frequent vulnerabilities that trigger forced upgrades, so it is good that sites can upgrade to the latest version of some email signing protocol without having to replace their entire mail system. As with my earlier example of specialization where different people make bread or clothes, specialization in software makes better software possible.