root / pykota / trunk / SECURITY @ 2638

Revision 2622, 9.3 kB (checked in by jerome, 19 years ago)

Added 2006 to the copyright's years.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
Line 
1# $Id$
2
3PyKota - Print Quotas for CUPS and LPRng
4
5(c) 2003, 2004, 2005, 2006 Jerome Alet <alet@librelogiciel.com>
6This program is free software; you can redistribute it and/or modify
7it under the terms of the GNU General Public License as published by
8the Free Software Foundation; either version 2 of the License, or
9(at your option) any later version.
10
11This program is distributed in the hope that it will be useful,
12but WITHOUT ANY WARRANTY; without even the implied warranty of
13MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
14GNU General Public License for more details.
15
16You should have received a copy of the GNU General Public License
17along with this program; if not, write to the Free Software
18Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
19
20====================================================================
21
22How 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====================================================================
Note: See TracBrowser for help on using the browser.