1 | # $Id$ |
---|
2 | |
---|
3 | PyKota - Print Quotas for CUPS and LPRng |
---|
4 | |
---|
5 | (c) 2003, 2004, 2005, 2006 Jerome Alet <alet@librelogiciel.com> |
---|
6 | This program is free software; you can redistribute it and/or modify |
---|
7 | it under the terms of the GNU General Public License as published by |
---|
8 | the Free Software Foundation; either version 2 of the License, or |
---|
9 | (at your option) any later version. |
---|
10 | |
---|
11 | This program is distributed in the hope that it will be useful, |
---|
12 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
---|
13 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
---|
14 | GNU General Public License for more details. |
---|
15 | |
---|
16 | You should have received a copy of the GNU General Public License |
---|
17 | along with this program; if not, write to the Free Software |
---|
18 | Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. |
---|
19 | |
---|
20 | ==================================================================== |
---|
21 | |
---|
22 | How to improve PyKota's security : |
---|
23 | ---------------------------------- |
---|
24 | |
---|
25 | - Secure your printers : |
---|
26 | |
---|
27 | This is the most important thing to do ! |
---|
28 | |
---|
29 | Tell them to refuse any print job not coming from your print server. |
---|
30 | Do this with telnet to set ACLs based on incoming IP addresses if |
---|
31 | possible, or through any other way. |
---|
32 | |
---|
33 | Put all your printers on a private unroutable subnet, different from |
---|
34 | the subnet on which your client hosts will reside. Ensure that the |
---|
35 | only machine allowed to access to this subnet is your print server. |
---|
36 | |
---|
37 | |
---|
38 | - Secure your print servers : |
---|
39 | |
---|
40 | Don't give shell access to your users on your print servers, and |
---|
41 | don't let them execute unauthorized commands : they could very well |
---|
42 | compile and/or execute tools like NetCat, and send datas directly to |
---|
43 | the printer in the case the printer is networked, thus bypassing the |
---|
44 | printing system and PyKota. |
---|
45 | |
---|
46 | Ensure that no regular user can read PyKota administrator's |
---|
47 | configuration file, but that both the PyKota Administrator and the |
---|
48 | user the printing system is run as can read it. With CUPS under |
---|
49 | Debian you may want to do : |
---|
50 | |
---|
51 | $ chown pykota.pykota ~pykota/pykota.conf ~pykota/pykotadmin.conf |
---|
52 | $ chmod 640 ~pykota/pykota.conf |
---|
53 | $ chmod 600 ~pykota/pykotadmin.conf |
---|
54 | |
---|
55 | Depending on your needs, you may want to put the user the printing |
---|
56 | system is run as in the group 'pykota', and relax permissions a bit |
---|
57 | so that this user can read the pykotadmin.conf file while printing. |
---|
58 | For example : |
---|
59 | |
---|
60 | $ chmod 640 ~pykota/pykotadmin.conf |
---|
61 | $ adduser lp pykota |
---|
62 | (this makes user 'lp' a member of group 'pykota') |
---|
63 | |
---|
64 | Another solution, needed on some systems : |
---|
65 | |
---|
66 | $ chmod a+rx ~pykota/ |
---|
67 | $ chown lp.pykota ~pykota/pykota.conf ~pykota/pykotadmin.conf |
---|
68 | |
---|
69 | Letting any user read PyKota administrator's configuration file may |
---|
70 | expose passwords or database information which would allow write |
---|
71 | access to the database, and so may transform your print quota |
---|
72 | management in a nightmare. |
---|
73 | |
---|
74 | If you want to let users generate their own print quota reports, |
---|
75 | then ensure that /etc/pykota/pykota.conf is readable by these users. |
---|
76 | To do this you can either put this users in the group 'pykota' while |
---|
77 | ensuring they can't read pykotadmin.conf with 'chmod 600 pykotadmin.conf' |
---|
78 | or simply allow everyone to read pykota.conf with 'chmod 644 pykota.conf' |
---|
79 | |
---|
80 | |
---|
81 | - Secure your database connections : |
---|
82 | |
---|
83 | Depending on the database backend used, either PostgreSQL or LDAP, |
---|
84 | you may have to take additionnal measures to render your database |
---|
85 | more secure. Please refer to your database system's documentation |
---|
86 | to learn how to do so. This is out of the scope of the present |
---|
87 | document which will only give basic informations. |
---|
88 | |
---|
89 | Keep in mind that if you use a centralized database, the first thing |
---|
90 | you may want to do is to restrict which hosts can access to it, i.e. |
---|
91 | only the print servers. |
---|
92 | |
---|
93 | PostgreSQL : |
---|
94 | |
---|
95 | For the PostgreSQL backend, PyKota already defines a user with |
---|
96 | read/write access and another user with read-only access to the |
---|
97 | Print Quota Database. PyKota doesn't set any passwords for these |
---|
98 | users though, but doing so is recommended, and here's how to do : |
---|
99 | |
---|
100 | From the root shell do : |
---|
101 | |
---|
102 | $ su - postgres |
---|
103 | $ psql template1 |
---|
104 | template1=# ALTER USER pykotauser WITH PASSWORD 'a.difficult.password'; |
---|
105 | template1=# ALTER USER pykotaadmin WITH PASSWORD 'another.password'; |
---|
106 | template1=# \q |
---|
107 | $ exit |
---|
108 | |
---|
109 | Now modify PostgreSQL's pg_hba.conf to restrict access to the PyKota |
---|
110 | database to PostgreSQL users 'pykotauser' and 'pykotaadmin' only, |
---|
111 | and only if they connect from localhost and provide the correct |
---|
112 | password. Here's an excerpt from our own pg_hba.conf : |
---|
113 | |
---|
114 | --- CUT --- |
---|
115 | local all postgres ident sameuser |
---|
116 | local all all reject |
---|
117 | host pykota pykotauser 127.0.0.1 255.255.255.255 crypt |
---|
118 | host pykota pykotaadmin 127.0.0.1 255.255.255.255 crypt |
---|
119 | host pykota all 127.0.0.1 255.255.255.255 reject |
---|
120 | --- CUT --- |
---|
121 | |
---|
122 | As an alternative, which may depend on the default encryption setting |
---|
123 | used by your version of PostgreSQL, you may want to use the following |
---|
124 | settings instead : |
---|
125 | |
---|
126 | --- CUT --- |
---|
127 | local all postgres ident sameuser |
---|
128 | local all all reject |
---|
129 | host pykota pykotauser 127.0.0.1 255.255.255.255 md5 |
---|
130 | host pykota pykotaadmin 127.0.0.1 255.255.255.255 md5 |
---|
131 | host pykota all 127.0.0.1 255.255.255.255 reject |
---|
132 | --- CUT --- |
---|
133 | |
---|
134 | Finally restart PostgreSQL so that the changes will be applied : |
---|
135 | |
---|
136 | $ /etc/init.d/postgresql restart |
---|
137 | |
---|
138 | Of course, depending on your needs, you may want to secure |
---|
139 | your database connections in a completely different way or |
---|
140 | add other security layers on top of this. To do so please |
---|
141 | refer to PostgreSQL's documentation because this is out of |
---|
142 | the scope of the present document. |
---|
143 | |
---|
144 | LDAP : |
---|
145 | |
---|
146 | For the LDAP backend, you have to ensure that no regular user can |
---|
147 | write to any PyKota specific attribute or objectClass. Otherwise |
---|
148 | they could modify their quota at will. Here too you will have to |
---|
149 | create two LDAP users which will be used for readonly and read+write |
---|
150 | access to PyKota's datas. PyKota currently doesn't do this, so |
---|
151 | you have to create an LDIF file this way (please adapt the |
---|
152 | DNs to your own environment) : |
---|
153 | |
---|
154 | --- CUT --- |
---|
155 | dn: cn=pykotauser,dc=example,dc=com |
---|
156 | cn: pykotauser |
---|
157 | objectClass: simpleSecurityObject |
---|
158 | objectClass: organizationalRole |
---|
159 | description: PyKota ReadOnly User |
---|
160 | userPassword: {CRYPT}jfdsk653dsZFL |
---|
161 | |
---|
162 | dn: cn=pykotaadmin,dc=example,dc=com |
---|
163 | cn: pykotaadmin |
---|
164 | objectClass: simpleSecurityObject |
---|
165 | objectClass: organizationalRole |
---|
166 | description: PyKota Read+Write User |
---|
167 | userPassword: {CRYPT}kqsIu43Exoi5s |
---|
168 | --- CUT --- |
---|
169 | |
---|
170 | Then add these two users to your existing LDAP tree : |
---|
171 | |
---|
172 | $ ldapadd -W -x -D "cn=admin,dc=example,dc=com" -f users.ldif |
---|
173 | |
---|
174 | Now modify your LDAP server's configuration to respectively allow |
---|
175 | read+write and readonly access to the datas : |
---|
176 | |
---|
177 | --- CUT --- |
---|
178 | by dn="cn=pykotaadmin,dc=example,dc=com" write |
---|
179 | by dn="cn=pykotauser,dc=example,dc=com" read |
---|
180 | --- CUT --- |
---|
181 | |
---|
182 | Finally restart your LDAP server so that the changes will be applied : |
---|
183 | |
---|
184 | $ /etc/init.d/slapd restart |
---|
185 | |
---|
186 | Of course, depending on your needs, you may want to secure |
---|
187 | your database connections in a completely different way or |
---|
188 | add other security layers on top of this. To do so please |
---|
189 | refer to your LDAP server's documentation because this is out |
---|
190 | of the scope of the present document. |
---|
191 | |
---|
192 | |
---|
193 | - Secure your CGI scripts : |
---|
194 | |
---|
195 | If you use printquota.cgi or dumpykota.cgi, ensure that the user |
---|
196 | they are run as can read the pykota.conf file but NOT the |
---|
197 | pykotadmin.conf file. |
---|
198 | |
---|
199 | The particular user they will be run as depends on your web server's |
---|
200 | settings. |
---|
201 | |
---|
202 | If you want to further restrict the access to these CGI scripts, |
---|
203 | please read your web server's documentation to add either |
---|
204 | encryption, authentication or both. |
---|
205 | |
---|
206 | The CGI scripts will honor the content of the REMOTE_USER CGI |
---|
207 | environment variable which is set by your web server if an |
---|
208 | authentication took place. If REMOTE_USER contains 'root' then, even |
---|
209 | if you didn't authenticate using the real root account and password, |
---|
210 | the scripts will consider they have been run by a PyKota |
---|
211 | administrator and will report all datas if asked to do so. If |
---|
212 | REMOTE_USER is not present, which means that you didn't chose to |
---|
213 | secure access to your CGI scripts, the same will happen. If |
---|
214 | REMOTE_USER contains something else, only datas pertaining to this |
---|
215 | user will be made available through the web. |
---|
216 | |
---|
217 | NB : In any case, the CGI scripts actually included in PyKota only |
---|
218 | do readonly accesses to PyKota's database. |
---|
219 | |
---|
220 | ==================================================================== |
---|