|
0
|
1 Design
|
|
|
2 ------
|
|
|
3
|
|
|
4 Security is the major goal of this project, with reliability coming second.
|
|
|
5 I also try to keep things fast, extensible and portable.
|
|
|
6
|
|
|
7 Things are broken into multiple processes running with minimal required
|
|
|
8 privileges. Communication between processes is trusted as little as
|
|
|
9 possible. Processes running as root are kept as simple as possible even if
|
|
|
10 it means minor performance hits.
|
|
|
11
|
|
969
|
12
|
|
0
|
13 imap-master
|
|
|
14 -----------
|
|
|
15
|
|
|
16 Runs as root. Executes new processes, some by itself and some by request of
|
|
|
17 another process. The requested processes can never be started as root, and
|
|
|
18 the allowed UID range can also be limited.
|
|
|
19
|
|
|
20 It's also possible to configure everything to be run under a single UID.
|
|
|
21 This is useful only if you wish to use imap somewhere you don't have root
|
|
|
22 access.
|
|
|
23
|
|
969
|
24
|
|
0
|
25 imap-login
|
|
|
26 ----------
|
|
|
27
|
|
|
28 Runs as non-privileged user (imapd). Handles accepting new client
|
|
|
29 connections and parsing commands until the client is authenticated. There
|
|
|
30 can be either a few of them which handle multiple connections, or one
|
|
|
31 process per connection. One per connection is much more secure in case it's
|
|
|
32 ever found to be exploitable, but it's also less efficient.
|
|
|
33
|
|
|
34 SSL and TLS connections are also fully handled by the login process.
|
|
|
35 Instead of passing the connection's fd to imap process, login creates a new
|
|
|
36 anonymous UNIX socket and uses it to translate communication between imap
|
|
|
37 process and the client. If you're using one login process per connection,
|
|
|
38 this also means that you have actually two processes all the time for an
|
|
|
39 active SSL IMAP connection.
|
|
|
40
|
|
|
41 Since SSL protocol is quite complex and I'm using gnutls which is still in
|
|
|
42 beta, it shouldn't be trusted to be fully secure. Using one login process
|
|
|
43 per connection should however make it quite safe to use, as the login is
|
|
|
44 running in a chrooted environment without any privileges. However, the
|
|
|
45 attacker could get your private SSL key..
|
|
|
46
|
|
|
47 Note that if you let a single login process handle multiple connections, a
|
|
|
48 security flaw would allow the attacker to see all the other user
|
|
|
49 connections connecting to it, possibly hijacking them or stealing their
|
|
|
50 passwords if plaintext authentication was used.
|
|
|
51
|
|
969
|
52
|
|
0
|
53 imap-auth
|
|
|
54 ---------
|
|
|
55
|
|
|
56 Runs under minimal required privileges to be able to authenticate users.
|
|
|
57 In case of shadow passwords or PAM, that's root. Communicates with
|
|
|
58 imap-login and imap-master to authenticate users.
|
|
|
59
|
|
|
60 * imap-login
|
|
|
61 - Receives LOGIN or AUTHENTICATE command
|
|
|
62 - Begins authentication with imap-auth process, with AUTHENTICATE
|
|
|
63 continuing passing data between client and imap-auth until done
|
|
|
64 - If successful, we've received a cookie which we send to imap-master
|
|
|
65 * imap-master
|
|
|
66 - Requests data from imap-auth for the cookie. Data includes
|
|
|
67 UID, GID and mail format and mail format specific data (eg.
|
|
|
68 mail directory). Optionally also receives chroot directory.
|
|
|
69 - Checks that the UID is in valid range, and that it's allowed
|
|
|
70 to be chrooted under given directory
|
|
|
71 - If everything is valid, pass the connection to imap process
|
|
|
72 - Replies to imap-login whether everything was valid
|
|
|
73 - If successful, stop processing the connection, imap process takes
|
|
|
74 care of the rest
|
|
|
75
|
|
|
76 * imap-auth
|
|
|
77 a) Receives authentication request with given protocol
|
|
|
78 - Initialize the request in protocol-specific manner
|
|
|
79 - If failed, send a failure-reply to client
|
|
969
|
80 - Otherwise send a cookie to client
|
|
0
|
81 b) Receives continued authentication request for given cookie
|
|
|
82 - Verifies that the cookie is valid, replying if not
|
|
|
83 - Handle the data in protocol-specific manner
|
|
|
84 - Reply to client with information whether the authentication
|
|
|
85 is finished
|
|
|
86 - Reset cookie expiration time
|
|
|
87 c) Receives a request to receive data associated to cookie
|
|
|
88 - Verifies that the cookie is valid, replying if not
|
|
|
89 - Reply with the data
|
|
|
90
|
|
969
|
91 Cookies are associated to a specific imap-login process, so one process
|
|
|
92 cannot steal another one's authentication request by pretending to be it.
|
|
|
93
|
|
|
94
|
|
0
|
95 imap
|
|
|
96 ----
|
|
|
97
|
|
|
98 Runs non-privileged and optionally chrooted (when it's safe). Since this is
|
|
|
99 the largest part of the imapd, this is where most of the potential security
|
|
|
100 flaws are.
|
|
|
101
|
|
|
102 Maildir and mbox formats use a few index files to look up data fast, the
|
|
|
103 actual mail files aren't opened unless they're really needed. The index
|
|
|
104 files are accessed using shared memory maps and locked using fcntl().
|
|
|
105
|
|
969
|
106 Using memory maps creates a security problem if the file isn't trusted. It
|
|
|
107 might well be possible to create a buffer overflow in some function by
|
|
|
108 modifying the file as while it's being used. Currently this should not be a
|
|
|
109 problem as we require write access to the files ourself, so attacker
|
|
|
110 shouldn't be able to get any extra privileges by exploiting the imap
|
|
|
111 process.
|
|
0
|
112
|
|
969
|
113 Other than the memory mapping problem, index files are not trusted to
|
|
|
114 contain valid data. Everything in them is validated before being used.
|
|
|
115
|
|
|
116 Supporting shared mailboxes will be a small problem. We probably shouldn't
|
|
|
117 even try to support using non-trusted index files but rather create trusted
|
|
|
118 indexes separately for each user. If however the users don't have direct
|
|
|
119 access to the indexes files, they could optionally be shared.
|
|
0
|
120
|
|
|
121
|
|
|
122 indexer
|
|
|
123 -------
|
|
|
124
|
|
|
125 Indexer may be started by master process when it thinks there's some extra
|
|
|
126 time to be used. It goes through users' mailboxes and compresses or
|
|
|
127 rebuilds indexes when it sees a need for it. The actual indexing is done by
|
|
|
128 dropping root privileges just as with imap process.
|
|
|
129
|
|
1240
|
130 Well, this is the plan anyway. The indexer doesn't exist yet.
|
