Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 378:c9a6cbce35fd

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
inserted non-break spaces where appropriate
author meillo@marmaro.de
date Tue, 03 Feb 2009 18:01:33 +0100
parents 91eb129dd695
children 850e2a474adb
comparison
equal deleted inserted replaced
377:90d5f98e3968 378:c9a6cbce35fd
90 90
91 91
92 \subsection{Security} 92 \subsection{Security}
93 \label{sec:current-code-security} 93 \label{sec:current-code-security}
94 94
95 Improvements to \masqmail's security are an important requirement and are the third task to work on. Retrofitting security \emph{into} \masqmail\ is not or hardly possible as it was explained in section \ref{sec:discussion-further-devel}. But adding wrappers and interposition filters can be a large step towards security. 95 Improvements to \masqmail's security are an important requirement and are the third task to work on. Retrofitting security \emph{into} \masqmail\ is not or hardly possible as it was explained in section~\ref{sec:discussion-further-devel}. But adding wrappers and interposition filters can be a large step towards security.
96 96
97 \subsubsection*{Mail security layers} 97 \subsubsection*{Mail security layers}
98 98
99 At first mail security layers like \name{smap} come to mind. The market share analysis in section \ref{sec:market-share} identified such software. This is an interposition filter that stands between the untrusted network and the \MTA. It accepts mail in replacement for the \MTA\ (also called \name{proxy}) in order to separate the \MTA\ from the untrusted network. 99 At first mail security layers like \name{smap} come to mind. The market share analysis in section~\ref{sec:market-share} identified such software. This is an interposition filter that stands between the untrusted network and the \MTA. It accepts mail in replacement for the \MTA\ (also called \name{proxy}) in order to separate the \MTA\ from the untrusted network.
100 100
101 The work \name{smap} does is described in \cite{cabral01}: \name{smap} accepts messages as proxy for the \MTA\ and puts it into a queue. \name{smapd} a brother program runs as daemon and watches for new messages in the queue which it submits into the \MTA\ then. 101 The work \name{smap} does is described in \cite{cabral01}: \name{smap} accepts messages as proxy for the \MTA\ and puts it into a queue. \name{smapd} a brother program runs as daemon and watches for new messages in the queue which it submits into the \MTA\ then.
102 102
103 Because the \MTA\ does not listen for connections from outside now, it is not directly vulnerable. But the \MTA\ can not react on relaying and spam on itself anymore because it has no direct connection to the mail sender. This job needs to be covered by the proxy now. Similar is the situation for encryption and authentication. However, care must be taken that the proxy stays small and simple as its own security will suffer otherwise. 103 Because the \MTA\ does not listen for connections from outside now, it is not directly vulnerable. But the \MTA\ can not react on relaying and spam on itself anymore because it has no direct connection to the mail sender. This job needs to be covered by the proxy now. Similar is the situation for encryption and authentication. However, care must be taken that the proxy stays small and simple as its own security will suffer otherwise.
104 104
106 106
107 \name{smap} is non-free software and thus no general choice for \masqmail. A way to achieve a similar setup would be to copy \masqmail\ and strip one copy to the bare minimum what is needed for the proxy job. \name{setuid} could be removed and root privilege too if \name{inetd} is used. This hardens the proxy instance. 107 \name{smap} is non-free software and thus no general choice for \masqmail. A way to achieve a similar setup would be to copy \masqmail\ and strip one copy to the bare minimum what is needed for the proxy job. \name{setuid} could be removed and root privilege too if \name{inetd} is used. This hardens the proxy instance.
108 108
109 Mail from outside would then come through the proxy into the system. Mail from the local host and from the local network could be directly accepted by the normal \masqmail, if those locations are considered trusted. But it seems better to have them use the proxy too, or maybe a second proxy instance with different policy. 109 Mail from outside would then come through the proxy into the system. Mail from the local host and from the local network could be directly accepted by the normal \masqmail, if those locations are considered trusted. But it seems better to have them use the proxy too, or maybe a second proxy instance with different policy.
110 110
111 The here described setup comes close to the structure of the incoming channels in the new design which is described in \ref{sec:new-design}. This shows the possibilities of the here chosen approach. %fixme: rethink this sentence 111 The here described setup comes close to the structure of the incoming channels in the new design which is described in section~\ref{sec:new-design}. This shows the possibilities of the here chosen approach. %fixme: rethink this sentence
112 112
113 113
114 \subsubsection*{A concrete setup} 114 \subsubsection*{A concrete setup}
115 115
116 A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system too. It takes input from \name{stdin} (by calling the \path{sendmail} command) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure \ref{fig:proxy-setup} depicts the setup. 116 A stripped down proxy needs to be created. It should only be able to receive mail via \SMTP, encrypt the communication, authenticate clients, and send mail out via \SMTP\ to an internal socket (named ``X'' in the figure). This is a straight forward task. The normal \masqmail\ instance runs on the system too. It takes input from \name{stdin} (by calling the \path{sendmail} command) and via \SMTP\ where it listens on an internal socket (named ``X'' in the figure). Outgoing mail is handled without difference to a regular setup. Figure~\ref{fig:proxy-setup} depicts the setup.
117 117
118 \begin{figure} 118 \begin{figure}
119 \begin{center} 119 \begin{center}
120 \includegraphics[scale=0.75]{img/proxy-setup.eps} 120 \includegraphics[scale=0.75]{img/proxy-setup.eps}
121 \end{center} 121 \end{center}
153 153
154 154
155 155
156 \subsection{Design decisions} 156 \subsection{Design decisions}
157 157
158 This section describes and discusses architectural decision that were made for the new design. To functional requirements is in most times only refered as they were already discussed in chapter \ref{chap:present-and-future}. 158 This section describes and discusses architectural decision that were made for the new design. To functional requirements is in most times only refered as they were already discussed in chapter~\ref{chap:present-and-future}.
159 159
160 A number of major design ideas lead the development of the new architecture: 160 A number of major design ideas lead the development of the new architecture:
161 \begin{enumerate} 161 \begin{enumerate}
162 \item throughout compartmentalization 162 \item throughout compartmentalization
163 \item free the internal system from the in and out channels; provide interfaces to add arbitrary protocol handlers afterwards 163 \item free the internal system from the in and out channels; provide interfaces to add arbitrary protocol handlers afterwards
171 171
172 \subsubsection*{Incoming channels} 172 \subsubsection*{Incoming channels}
173 173
174 The functional requirements for incoming and outgoing 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. 174 The functional requirements for incoming and outgoing 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.
175 175
176 A bit different is the structure of \name{sendmail X} at that point: Locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a back door? 176 A bit different is the structure of \name{sendmail~X} at that point: Locally submitted messages go to the \SMTP\ daemon, which is the only connection towards the mail queue. %fixme: is it a smtp dialog? or a back door?
177 \person{Finch} proposes a similar approach \cite{finch-sendmail}. He wants the \texttt{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 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. 177 \person{Finch} proposes a similar approach \cite{finch-sendmail}. He wants the \texttt{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 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.
178 178
179 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. Also the \SMTP\ modules can be removed if it is not needed. It is better to have more independent modules if each one is simpler then. The need to implement an \SMTP\ client in each one makes the modules more complicated. 179 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. Also the \SMTP\ modules can be removed if it is not needed. It is better to have more independent modules if each one is simpler then. The need to implement an \SMTP\ client in each one makes the modules more complicated.
180 180
181 With the increasing need for new protocols in mind, it seems better to have single modules for each incoming channel, although this leads to duplicated acceptance checks. Independent checks in different modules, however, have the advantage of simply applying different policies. Thus it is possible to run two \SMTP\ modules that listen on different ports: one accessible from the Internet which requires authentication, the other one only accessible from the local network without authentication. 181 With the increasing need for new protocols in mind, it seems better to have single modules for each incoming channel, although this leads to duplicated acceptance checks. Independent checks in different modules, however, have the advantage of simply applying different policies. Thus it is possible to run two \SMTP\ modules that listen on different ports: one accessible from the Internet which requires authentication, the other one only accessible from the local network without authentication.
188 188
189 \subsubsection*{Outgoing channels} 189 \subsubsection*{Outgoing channels}
190 190
191 Outgoing mail is commonly either sent using \SMTP, piped into local commands (for example \path{uucp}), or delivered locally by appending to a mailbox. 191 Outgoing mail is commonly either sent using \SMTP, piped into local commands (for example \path{uucp}), or delivered locally by appending to a mailbox.
192 192
193 Outgoing channels are similar for \qmail, \postfix, and \name{sendmail X}: All of them have a module to send mail using \SMTP\ and one for writing into a local mailbox. Local mail delivery is a job that should have root privilege to be able to switch to any user in order to write to his mailbox. Modular \MTA{}s do not require \name{setuid root} but the local delivery process (or its parent) should run as root. root privilege is not a mandatory requirement but any other approach has some disadvantages thus commonly root privilege is used. 193 Outgoing channels are similar for \qmail, \postfix, and \name{sendmail~X}: All of them have a module to send mail using \SMTP\ and one for writing into a local mailbox. Local mail delivery is a job that should have root privilege to be able to switch to any user in order to write to his mailbox. Modular \MTA{}s do not require \name{setuid root} but the local delivery process (or its parent) should run as root. root privilege is not a mandatory requirement but any other approach has some disadvantages thus commonly root privilege is used.
194 194
195 Local mail delivery should not be done by the \MTA, but by an \NAME{MDA} instead. This decision was discussed in section \ref{sec:functional-requirements}. This means only an outgoing channel that pipes mail into a local command is required for local delivery. 195 Local mail delivery should not be done by the \MTA, but by an \NAME{MDA} instead. This decision was discussed in section~\ref{sec:functional-requirements}. This means only an outgoing channel that pipes mail into a local command is required for local delivery.
196 196
197 Other outgoing channels, one for each supported protocol, should be designed like it was done in other \MTA{}s. 197 Other outgoing channels, one for each supported protocol, should be designed like it was done in other \MTA{}s.
198 198
199 199
200 200
277 277
278 278
279 279
280 \subsubsection*{Spam and malware handling} 280 \subsubsection*{Spam and malware handling}
281 281
282 The two approaches for spam handling were already presented to the reader in section \ref{sec:functional-requirements} as \RF\,8 and \RF\,9. Here they are described in more detail: 282 The two approaches for spam handling were already presented to the reader in section~\ref{sec:functional-requirements} as \RF\,8 and \RF\,9. Here they are described in more detail:
283 283
284 \begin{enumerate} 284 \begin{enumerate}
285 \item Refusing spam during the \SMTP\ dialog. This is the way it was meant by the designers of the \SMTP\ protocol. They thought checking the sender and recipient mail addresses would be enough, but as they are forgeable it is not. More and more complex checks need to be done. Checking needs time, but \SMTP\ dialogs time out if it takes too long. Thus only limited time during the \SMTP\ dialog can be used for checking if a message seems to be spam. The advantage is that bad messages can simply get refused---no responsibility for the message is taken and no further system load is added. See \RFC\,2505 (especially section 1.5) for detail. 285 \item Refusing spam during the \SMTP\ dialog. This is the way it was meant by the designers of the \SMTP\ protocol. They thought checking the sender and recipient mail addresses would be enough, but as they are forgeable it is not. More and more complex checks need to be done. Checking needs time, but \SMTP\ dialogs time out if it takes too long. Thus only limited time during the \SMTP\ dialog can be used for checking if a message seems to be spam. The advantage is that bad messages can simply get refused---no responsibility for the message is taken and no further system load is added. See \RFC\,2505 (especially section 1.5) for detail.
286 286
287 \item Checking for spam after the mail was accepted and queued. Here more processing time can be invested, thus more detailed checks can be done. But, as responsibility for messages was taken by accepting them, it is no choice to simply delete spam mail. Checks for spam do not lead to sure results, they just indicate the possibility the message is unwanted mail. \person{Eisentraut} indicates actions to take after a message is recognized as probably spam \cite[pages 18--20]{eisentraut05}. The only acceptable one, for mail the \MTA\ is responsible for, is adding further or rewriting existing header lines. Thus all further work on the message is the same as for non-spam messages. 287 \item Checking for spam after the mail was accepted and queued. Here more processing time can be invested, thus more detailed checks can be done. But, as responsibility for messages was taken by accepting them, it is no choice to simply delete spam mail. Checks for spam do not lead to sure results, they just indicate the possibility the message is unwanted mail. \person{Eisentraut} indicates actions to take after a message is recognized as probably spam \cite[pages 18--20]{eisentraut05}. The only acceptable one, for mail the \MTA\ is responsible for, is adding further or rewriting existing header lines. Thus all further work on the message is the same as for non-spam messages.
319 319
320 320
321 321
322 \subsection{The resulting architecture} 322 \subsection{The resulting architecture}
323 323
324 The result is a symmetric design, featuring the following parts: Any number of handlers for incoming connections to receive mail. A module that stores the received mail into a first queue. A central scanning module take mail from the first queue, processes it in various ways, and puts it afterwards into a second queue. A module that takes it out of the second queue and passes it to a matching transport module. A set of transport modules that transfers the message to the destination. In other words three main modules (\name{queue-in}, \name{scanning}, \name{queue-out}) are connected by two queues (\name{incoming}, \name{outgoing}). On each end is a set of modules to receive or send mail---one for each protocol. The \name{pool} is part of the queue; it is the place where the bodies of the queued messages are stored. Figure \ref{fig:masqmail-arch-new} depicts the new designed architecture. 324 The result is a symmetric design, featuring the following parts: Any number of handlers for incoming connections to receive mail. A module that stores the received mail into a first queue. A central scanning module take mail from the first queue, processes it in various ways, and puts it afterwards into a second queue. A module that takes it out of the second queue and passes it to a matching transport module. A set of transport modules that transfers the message to the destination. In other words three main modules (\name{queue-in}, \name{scanning}, \name{queue-out}) are connected by two queues (\name{incoming}, \name{outgoing}). On each end is a set of modules to receive or send mail---one for each protocol. The \name{pool} is part of the queue; it is the place where the bodies of the queued messages are stored. Figure~\ref{fig:masqmail-arch-new} depicts the new designed architecture.
325 325
326 \begin{figure} 326 \begin{figure}
327 \begin{center} 327 \begin{center}
328 \includegraphics[width=\textwidth]{img/masqmail-arch-new.eps} 328 \includegraphics[width=\textwidth]{img/masqmail-arch-new.eps}
329 \end{center} 329 \end{center}
330 \caption{A new designed architecture for \masqmail} 330 \caption{A new designed architecture for \masqmail}
331 \label{fig:masqmail-arch-new} 331 \label{fig:masqmail-arch-new}
332 \end{figure} 332 \end{figure}
333 333
334 This architecture is heavily influenced by the ones of \qmail\ and \postfix. Both have different incoming channels that merge in the module that puts mail into the queue; central is the queue (or more of them); and one module takes mail from the queue and passes it to one of the outgoing channels. Mail processing is built into the architecture in a more explicit way than it was done in \qmail\ and \postfix. It is more similar to the \NAME{AR} module of \name{sendmail X}, which is the central point for spam checking. 334 This architecture is heavily influenced by the ones of \qmail\ and \postfix. Both have different incoming channels that merge in the module that puts mail into the queue; central is the queue (or more of them); and one module takes mail from the queue and passes it to one of the outgoing channels. Mail processing is built into the architecture in a more explicit way than it was done in \qmail\ and \postfix. It is more similar to the \NAME{AR} module of \name{sendmail~X}, which is the central point for spam checking.
335 335
336 Special regard was put on addable support for further mail transfer protocols. This appears to be most similar to \qmail, which was designed to handle multiple protocols. 336 Special regard was put on addable support for further mail transfer protocols. This appears to be most similar to \qmail, which was designed to handle multiple protocols.
337 337
338 338
339 \subsubsection*{The modules} 339 \subsubsection*{The modules}
350 The \name{queue-out} module takes messages from the \name{outgoing} queue, queries information about the online state which specifies the route to use, and passes the messages to the correct transport module. Successfully transferred messages are removed from the \name{outgoing} queue. This module handles the \masqmail\ specific task of the route management. 350 The \name{queue-out} module takes messages from the \name{outgoing} queue, queries information about the online state which specifies the route to use, and passes the messages to the correct transport module. Successfully transferred messages are removed from the \name{outgoing} queue. This module handles the \masqmail\ specific task of the route management.
351 351
352 352
353 \name{Receiver modules} 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 a more secure replacement like \person{Bernstein}'s \name{ucspi-tcp}. This makes it possible to run them with least privilege. 353 \name{Receiver modules} 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 a more secure replacement like \person{Bernstein}'s \name{ucspi-tcp}. This makes it possible to run them with least privilege.
354 354
355 \name{Transport modules}, on the opposite side of the system, are the modules that send outgoing mail. They are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module which acts as an \SMTP\ client and the \name{pipe} module to interface gateways to other systems or networks like fax and \NAME{UUCP}. A module for local delivery is not included, \masqmail\ passes this job to an \NAME{MDA} (like \name{procmail}) (see section \ref{sec:functional-requirements} for reasons). The \NAME{MDA} gets invoked through the \name{pipe} module. 355 \name{Transport modules}, on the opposite side of the system, are the modules that send outgoing mail. They are the interface between \name{queue-out} and remote hosts or local commands for further processing. The most popular ones are the \name{smtp} module which acts as an \SMTP\ client and the \name{pipe} module to interface gateways to other systems or networks like fax and \NAME{UUCP}. A module for local delivery is not included, \masqmail\ passes this job to an \NAME{MDA} (like \name{procmail}) (see section~\ref{sec:functional-requirements} for reasons). The \NAME{MDA} gets invoked through the \name{pipe} module.
356 356
357 357
358 358
359 359
360 \subsubsection*{The queue} 360 \subsubsection*{The queue}
381 381
382 Communication between modules is required to exchange data and status information. This is also called ``Inter-process communication'' (short: \NAME{IPC}) because the modules are independent programs in this case and processes are programs in execution. 382 Communication between modules is required to exchange data and status information. This is also called ``Inter-process communication'' (short: \NAME{IPC}) because the modules are independent programs in this case and processes are programs in execution.
383 383
384 The connections between \name{queue-in} and \name{scanning}, as well as between \name{scanning} and \name{queue-out} is provided by the queues, only sending signals to trigger runs may be useful. Communication between receiving and transport modules and the outside world are done using the specific protocol they do handle. 384 The connections between \name{queue-in} and \name{scanning}, as well as between \name{scanning} and \name{queue-out} is provided by the queues, only sending signals to trigger runs may be useful. Communication between receiving and transport modules and the outside world are done using the specific protocol they do handle.
385 385
386 Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged using \unix\ pipes and a simple protocol. Figure \ref{fig:ipc-protocol} shows a state diagram for the protocol. Solid lines indicate client actions, dashed lines indicate server responses. 386 Left is only communication between the receiver modules and \name{queue-in}, and between \name{queue-out} and the transport modules. Data is exchanged using \unix\ pipes and a simple protocol. Figure~\ref{fig:ipc-protocol} shows a state diagram for the protocol. Solid lines indicate client actions, dashed lines indicate server responses.
387 387
388 \begin{figure} 388 \begin{figure}
389 \begin{center} 389 \begin{center}
390 \includegraphics[scale=0.75]{img/ipc-protocol.eps} 390 \includegraphics[scale=0.75]{img/ipc-protocol.eps}
391 \end{center} 391 \end{center}