root / pykota / trunk / SECURITY @ 3301

Revision 3281, 9.2 kB (checked in by jerome, 17 years ago)

PyKota supports more than 2 database backends for a long time now.

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