Digg this story   Add to del.icio.us   (page 3 of 3 ) previous 
From Physics to Security
Federico Biancuzzi, 2008-09-16

Story continued from Page 2

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.

Federico Biancuzzi is freelancer; in addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.
    Digg this story   Add to del.icio.us   (page 3 of 3 ) previous 
Comments Mode:
From Physics to Security 2008-09-19
Security Admin
From Physics to Security 2008-09-19
Anonymous (2 replies)
Re: From Physics to Security 2008-09-22
Re: From Physics to Security 2008-09-24
Robert Lemos
Authors Avatar 2008-09-22
Anonymous (1 replies)
Re: Authors Avatar 2008-09-23
Federico Biancuzzi
From Physics to Security 2008-09-22
Public awareness is required as well 2008-09-22
flash tekkie
A Non-Stochastic Plan for SPAM 2008-09-26


Privacy Statement
Copyright 2010, SecurityFocus