docs/diploma: thesis/tex/5-Improvements.tex comparison

comparison thesis/tex/5-Improvements.tex @ 396:8ef85e22ff7d

again lots of fixes and removed fixmes

author	meillo@marmaro.de
date	Sat, 07 Feb 2009 19:00:25 +0100
parents	0d78755132b7
children	13e630c5a44d

comparison

equal deleted inserted replaced

-:0d78755132b7
+:8ef85e22ff7d
 \SMTP\ authentication (also referred to as \NAME{SMTP-AUTH}) support is easiest attained by using a \name{Simple Authentication and Security Layer} (short: \NAME{SASL}) implementation. \person{Dent} sees in \NAME{SASL} the best solution for dynamic authentication of users:
 \index{smtp-auth}
 \index{sasl}
 \begin{quote}
-%None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.
 None of these [authentication methods] is an ideal solution. They require additional code compiled into your existing daemons that may then require special write access to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of your users' mail pass through your system no matter where they are on the Internet, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
 \hfill\cite[page~44]{dent04}
 \end{quote}
 These days \NAME{SMTP-AUTH}---defined in \RFC\,2554---is supported by almost all email clients. If encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
 \index{auth!backend}
 For a small \MTA\ like \masqmail, it seems preferable to store the login data in a text file under \masqmail's control. This is the most simple choice for many usage scenarios. But using a central authentication facility has advantages in larger setups, too. \name{Cyrus} \NAME{SASL} supports both, so there is no problem. If \name{gsasl} is chosen, it seems best to start with an authentication file under \masqmail's control.
-%fixme: << how could this be covered by architecture (e.g. smtp submission). >>
 	\item Concentrate on the mail transfer job. Use specialized external programs for other jobs.
 	\item Keep it simple, clear, and general.
 \end{enumerate}
 \index{compartmentalization}
-%fixme: << conditional compilation >>
 \subsubsection*{Incoming channels}
 \index{incoming channels}
 The functional requirements for incoming channels were already discussed as \RF\,1 on page~\pageref{rf1}. Two required incoming channels were identified: the \path{sendmail} command for local mail submission and the \SMTP\ daemon for remote connections.
 \index{sendmail!command}
-A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go also to the \SMTP\ daemon, which is the only connection to the mail queue. %fixme: is it a smtp dialog? or a back door?
+A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go also to the \SMTP\ daemon, which is the only connection to the mail queue. \person{Finch} proposes a similar approach \cite{finch-sendmail}: He wants the \path{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA, like it is done by connections from remote. The advantage here is to have one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid}, because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
-\person{Finch} proposes a similar approach \cite{finch-sendmail}: He wants the \path{sendmail} command to be a simple \SMTP\ client that contacts the \SMTP\ daemon of the \MTA, like it is done by connections from remote. The advantage here is to have one single module where all \SMTP\ dialog with submitters is done. Hence one single point to accept or refuse incoming mail. Additionally does the module which puts mail into the queue not need to be \name{setuid} or \name{setgid}, because it is only invoked from the \SMTP\ daemon. The \MTA's architecture would become simpler and common tasks are not duplicated in modules that do similar jobs.
 \index{sendmailx}
 \index{smtp}
 \index{setuid}
 But merging the input channels in the \SMTP\ daemon makes the \MTA\ heavily dependent on \SMTP. To \qmail\ and \postfix\ new protocol handlers may be added without change in other parts of the system. The \SMTP\ modules can even get removed if it is not needed. It is better to have a larger number of independent modules if each one is simpler then. The need to implement \SMTP\ clients in every module for internal communication makes them more complicated.
 \index{postfix}
 \qmail\ has the principle of ``don't parse'' which propagates the avoidance of parsing as much as possible. The reason is that parsing is a highly complex task which likely makes code exploitable.
 \index{qmail}
-In \masqmail's new design, mail should be stored into the queue without parsing. A scanning module should then parse the message with high care. It seems best to use a \name{parser generator}\footnote{\person{Stephen~C.\ Johnson}'s paper about \name{yacc} is a good introduction into \name{parser generators} \cite{johnson79}.} for this work. The parsed data should then get modified if needed and written into a second queue. This approach has several advantages. First, the receiving parts of the system are independent from content, they simply store it into the queue. Second, one single module does the parsing and generates new messages that contain only valid data. Third, the sending parts of the system will thus only work on messages that consist of valid data. Of course, it must be ensured that each message passes through the \name{scanning} module, but this is already required for spam and malware scanning.
+In \masqmail's new design, mail should be stored into the queue without parsing. A scanning module should then parse the message with high care. \person{Spinellis} proposes reliable approaches to do this work \cite[pages~17--18]{spinellis06}; using a \name{parser generator}\footnote{\person{Stephen~C.\ Johnson}'s paper about \name{yacc} is a good introduction into \name{parser generators} \cite{johnson79}.} is the best solution here. The parsed data should then get modified if needed and written into a second queue. This approach has several advantages. First, the receiving parts of the system are independent from content, they simply store it into the queue. Second, one single module does the parsing and generates new messages that contain only valid data. Third, the sending parts of the system will thus only work on messages that consist of valid data. Of course, it must be ensured that each message passes through the \name{scanning} module, but this is already required for spam and malware scanning.
-%fixme: ref for parser generator
 \index{parser generator}
 The mail body will never get modified, except for removing and adding transfer protocol specific requirements like dot stuffing or special line ending characters. These translations are only done in receiving and sending modules.
 \person{Jon Postel}'s robustness principle\footnote{``Be liberal in what you accept, and conservative in what you send.''. In this wording in \RFC\,1122 and in different wordings in numerous \RFC{}s} should be respected in the \name{scanning} module. The module should parse the given input in a liberal way and generate clean output. \person{Raymond}'s \name{Rule of Repair}\footnote{``Repair what you can -- but when you must fail, fail noisily and as soon as possible.'' \cite[page~18]{raymond03}} can be applied, too. But it is important to repair only obvious problems, because repairing functionality is likely a target for attacks.
 \subsubsection*{Route management}
 \index{online routes}
-The online state is only important for the sending modules of the system, thus it should be queried in the \name{queue-out} module which selects ready messages from the \name{outgoing} queue and transfers them to the appropriate sending module. Route-based aliasing, which was described in the last section, %fixme: is this still true?
+The online state is only important for the sending modules of the system, thus it should be queried in the \name{queue-out} module which selects ready messages from the \name{outgoing} queue and transfers them to the appropriate sending module. Route-based aliasing, which was described in the last section, should be done in the same go.
-should be done in the same go.
 \subsubsection*{Archiving}
 \index{archiving}
 \paragraph{Receiver modules}
 \index{incoming channels}
 They are the communication interface between external senders and the \name{queue-in} module. Each protocol needs a corresponding \name{receiver module} to be supported. Most popular is the \name{sendmail} module, which is a command to be called from the local host, and the \name{smtpd} module which usually listens on port 25. Other modules to support other protocols may be added as needed. Receiving modules that need to listen on ports should get invoked by \name{inetd}, or by \person{Bernstein}'s more secure \name{ucspi-tcp}. This makes it possible to run them with least privilege.
+\index{least privilege}
 \paragraph{The \name{queue-in} module}
 \index{mail queue}
 Its job is to store new messages into the queue. When one of the receiving modules has a new message, it invokes the \name{queue-in} module which creates a spool file in the \name{incoming} queue and a data file in the \name{pool}. The receiver module then sends the envelope, the message header, and the message body. The \name{queue-in} modules writes the first two into the spool file, the latter one into the \name{pool}.
 The modules \name{scanning} and \name{queue-out} are candidates for all-time running daemon processes. Alternatively they could be started by \name{cron} to do single runs.
 Another possibility is to run a master process as daemon which starts and restarts the system parts. \postfix\ has such a master process, \qmail\ lacks it. The jobs of a master process can be done by other tools of the operating system too, thus making a master process abdicable. \masqmail\ does probably better go without a master process, because it aims to save resources, not to get the best performance.
 \index{master process}
-A sane permission management is very important for secure software in general. The \name{principle of least privilege}, as it is often called, should be respected. If it is possible to use lower privilege then it should be done. An example for doing so is the \name{smtpd} module. It is a server module which listens on a port. One way is to start it as root and let it bind to the port and drop all privilege before it does any other work. But root privilege is avoidable completely if \name{inetd}, or one of its substitutes, listens on the port instead of the \name{smtpd} module. \name{inetd} will then launch the \name{smtpd} module to handle the connection whenever a connection attempt to the port is made. The \name{smtpd} module needs no privilege at all this way.
+A sane permission management is very important for secure software in general. The \name{principle of least privilege} \cite[section~I.A.3.f]{saltzer75}, as it is often called, should be respected. If it is possible to use lower privilege then it should be done. An example for doing so is the \name{smtpd} module. It is a server module which listens on a port. One way is to start it as root and let it bind to the port and drop all privilege before it does any other work. But root privilege is avoidable completely if \name{inetd}, or one of its substitutes, listens on the port instead of the \name{smtpd} module. \name{inetd} will then launch the \name{smtpd} module to handle the connection whenever a connection attempt to the port is made. The \name{smtpd} module needs no privilege at all this way.

Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 396:8ef85e22ff7d