1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Horde/IMP Security Notes docs/SECURITY
=--------------------------------------------------------------------------=
$Horde: imp/docs/SECURITY,v 1.1.2.9 2001/05/22 03:00:17 bjn Exp $
Preventing attachment temporary file race conditions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IMP uses the PHP tempnam() function call to create temporary files
related to attachment uploading (during compose) and viewing (using
viewers). As of PHP 4.0.3, PHP tempnam() calls the mkstemp() function
which is designed to prevent mischief such as /tmp races, symbolic
link retargeting, etc.
Sites using PHP earlier than 4.0.3 (including the 3.0.x series) need
to patch their PHP code so that tempnam() calls mkstemp(); otherwise,
you will be vulnerable to such abuse by local users.
Sites may also gain increased security by defining an upload_tmp_dir
(in the PHP .ini file) which is writable by the web server, but not by
all users.
(Thanks to Jarno Huuskonen <Jarno.Huuskonen@uku.fi> for identifying
these issues.)
Default database password is a security hole
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Horde and IMP documentation and sample database creation scripts
create a user "hordemgr" with password "hordemgr" for accessing the
horde database. Using this password in a production environment is a
security hole, since an attacker will easily guess it.
It is very important that you change the password of the "hordemgr"
user to something secure. The horde/scripts/database/dbpasswd.sh
script can be used to make this change, or alter the instructions in
horde/docs/DATABASE to set a different password.
IMP will display an error on the login page if the default database
password is in use. If you insist on using the default password (NOT
RECOMMENDED), the error can be turned off in imp/config/defaults.php3
by setting "$default->db_security_nag = false".
Preventing local users from reading configuration files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The PHPLIB, Horde, and IMP configuration files contain sensitive data
(such as database passwords) that should not be read by local system
users. If your IMP server allows untrusted users to log in, one way to
make the configuration directories accessible only to the web server is
as follows:
# chgrp nobody /home/httpd/horde-phplib/local.inc
# chgrp -R nobody /home/httpd/html/horde/config
# chgrp -R nobody /home/httpd/html/horde/imp/config
# chmod o-rwx /home/httpd/horde-phplib/local.inc
# chmod -R o-rwx /home/httpd/html/horde/config
# chmod -R o-rwx /home/httpd/html/horde/imp/config
(The paths above will vary depending on where you have PHPLIB and Horde
installed.) For completely fascist permissions, you can make the entire
PHPLIB/Horde/IMP trees inaccessible except by the web server:
# chgrp -R nobody /home/httpd/horde-phplib
# chgrp -R nobody /home/httpd/html/horde
# chmod -R o-rwx /home/httpd/horde-phplib
# chmod -R o-rwx /home/httpd/html/horde
This assumes that the web server runs as group "nobody" (typical for
Apache); if not, you'll want to change the above commands accordingly.
Also note that other applications (such as NFS) can run as "nobody",
so this may not be a complete solution for your environment.
Preventing Apache from serving configuration and source files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Horde and IMP configuration files contain sensitive data (such as
database passwords) that should not be served by the web server. Other
directories contain PHP source code that isn't intended for viewing
by end-users. One way to prevent the web server from serving these
files is to add sections to httpd.conf such as the following:
<Directory "/home/httpd/html/horde/config">
order deny,allow
deny from all
</Directory>
<Directory "/home/httpd/html/horde/lib">
order deny,allow
deny from all
</Directory>
<Directory "/home/httpd/html/horde/locale">
order deny,allow
deny from all
</Directory>
<Directory "/home/httpd/html/horde/templates">
order deny,allow
deny from all
</Directory>
<Directory "/home/httpd/html/horde/imp/config">
order deny,allow
deny from all
</Directory>
<Directory "/home/httpd/html/horde/imp/lib">
order deny,allow
deny from all
</Directory>
<Directory "/home/httpd/html/horde/imp/locale">
order deny,allow
deny from all
</Directory>
<Directory "/home/httpd/html/horde/imp/templates">
order deny,allow
deny from all
</Directory>
Web-based setup script
~~~~~~~~~~~~~~~~~~~~~~
Note that the file setup.php3 can be used to configure IMP over the
web. This is insecure. For this reason, it should not be readable while
IMP is in use, and IMP, in fact, checks to make sure that it is not.
Please see the docs/INSTALL file on the use of install.sh and secure.sh
before and after configuring IMP with setup.php3.
Caching
~~~~~~~
All caching flags have been flipped in order to make sure that no
caching takes place. You can turn on web local caching within your
defaults.php3 file (default->cache_pages) but it isn't recommended as
it is a security risk. Netscape doesn't handle non-cached pages very
well and if you are in a compose window and you resize your screen you
will lose the data inside of it. Mozilla/Netscape5 will change this.
Using a secure web server
~~~~~~~~~~~~~~~~~~~~~~~~~
index.php3 is the root of the frame system. If you want IMP to use a secure
connection (SSL), then you need to somehow make sure that users access IMP
as https://your.server.here/your/path/to/imp/, not as http://blah...
Note on MySQL socket security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If your MySQL keeps its socket (mysql.sock) in a directory like /tmp
or /var/tmp, you need to set permissions carefully to ensure that
local users (if you have them) can't delete the socket. The "sticky"
bit should already be sent on the temporary directory itself, but you
also need to make sure the socket itself isn't writable by "other",
or users can delete it.
My opinion is that /var/run or /var/lib/mysql (or the MySQL top-level
directory) makes a better location for the MySQL socket.
-- Brent <bjn@horde.org>
Additional Notes
~~~~~~~~~~~~~~~~
This is by far not a complete HOWTO. This is just a compiled list of what
people have contributed so far. If you have tips, ideas, suggestions or
anything else that you think could help others in securing their IMP
installation, please let us know. <dev@lists.horde.org>
|
