Mercurial > docs > diploma

comparison thesis/tex/5-Improvements.tex @ 324:8671d9c0f29a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
wrote more about auth and about security
author meillo@marmaro.de
date Thu, 22 Jan 2009 21:54:52 +0100
parents 426ad56236ce
children 802635628c92
comparison
equal deleted inserted replaced
323:82496704f747 324:8671d9c0f29a
66 %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. 66 %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.
67 None of these [authentication methods] 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, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users. 67 None of these [authentication methods] 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, \NAME{SASL} is probably the solution that offers the most reliable and scalable method to authenticate users.
68 \hfill\cite[page 44]{dent04} 68 \hfill\cite[page 44]{dent04}
69 \end{quote} 69 \end{quote}
70 70
71 In the meanwhile is \NAME{SMTP-AUTH} supported by most email clients and if encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure. 71 These days is \NAME{SMTP-AUTH}, which is defined in \RFC\,2554, supported by most email clients. If encryption is used then even insecure authentication methods like \NAME{PLAIN} and \NAME{LOGIN} become secure.
72 72
73 << what to do in code (same like for enc?) >> 73 \masqmail\ best uses an available \NAME{SASL} library. \name{Cyrus} \NAME{SASL} is used by \postfix\ and \sendmail. It is a complete framework that makes use of existing authentication concepts like \path{/etc/passwd} or \NAME{PAM}. As advantage it can be included in existing user data bases. \name{gsasl} is an alternative. It comes as a library which helps on deciding for a method and on generating the appropriate dialog data; the actual transmission of the data and the authentication against some database is left open to the programmer. \name{gsasl} is used by \name{msmtp} for example. It seems best to give both concepts a try and decide then which one to use.
74 74
75 << where to store login data >> 75 Currently, outgoing connections already feature \SMTP-\NAME{AUTH} but only in a hand-coded way. It is to decide wether it remains as it is or gets replaced by the \NAME{SASL} approach, that is used for incoming connections. The decision should be based on the estimated time until the new design is usable.
76
77 Authentication needs code changes at the same places as encryption. The relevant code files are \path{smtp_in.c}, \path{smtp_out.c}, and \path{conf.c}.
78
79 The server code, to authenticate clients, must be added to \path{smtp_in.c} and the configuration options to \path{conf.c}. Several configuration options should be provided: the authentication policy (no authentication, offer authentication, insist on authentication), the authentication backend (if several are supported), an option to refuse plain text methods (\NAME{PLAIN} and \NAME{LOGIN}), and one to require encryption before authentication.
80
81 If the authentication code for outgoing connects shall be changed too, it must be done in \path{smtp_out.c}. The configuration options are already present.
82
83
84 About the authentication backend. For a small \MTA\ like \masqmail, it seems preferrable 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.
85
86
87
76 88
77 89
78 << Compare static with dynamic authentication: pros and cons; usecases: when to use what; >> 90 << Compare static with dynamic authentication: pros and cons; usecases: when to use what; >>
79 91
80 << how could this be covered by architecture (e.g. smtp submission). >> 92 << how could this be covered by architecture (e.g. smtp submission). >>
81 93
82 94
83 95
96
97
84 \subsubsection*{Security} 98 \subsubsection*{Security}
85 99
86 by using wrappers and interposition filters 100 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.
101
102 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.
103
104 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.
105
106 Because the \MTA\ does not listen for connections from extern now, it is not directly attackable. 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.
107
108 The advantage is that the \MTA\ itself needs not to bother much with untrusted environments. And a small proxy cares only about that work.
109
110 \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.
111
112
87 113
88 split masqmail into two instances 114 split masqmail into two instances
89 115
90 \begin{verbatim} 116 \begin{verbatim}
91 +--------+ ext ||||| int +--------+ 117 +--------+ ext ||||| int +--------+
93 |masqmail| pos |masqmail| 119 |masqmail| pos |masqmail|
94 +--------+ ||||| +--------+ 120 +--------+ ||||| +--------+
95 \end{verbatim} 121 \end{verbatim}
96 122
97 << refer back to enc and auth >> 123 << refer back to enc and auth >>
124
125 << conditional compilation >>
98 126
99 127
100 \subsubsection*{Reliability} 128 \subsubsection*{Reliability}
101 129
102 discuss persistence through using databases 130 discuss persistence through using databases