Changeset 3413 for pykota/trunk/SECURITY

Show
Ignore:
Timestamp:
09/27/08 22:02:37 (16 years ago)
Author:
jerome
Message:

Removed unnecessary spaces at EOL.

Files:
1 modified

Legend:

Unmodified
Added
Removed

  • pykota/trunk/SECURITY

    r3281 r3413  
    2222---------------------------------- 
    2323 
    24   - Secure your printers :   
    25    
     24  - Secure your printers : 
     25 
    2626    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     
     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 
    5151        $ chmod 640 ~pykota/pykota.conf 
    5252        $ 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      
     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 
    5959        $ chmod 640 ~pykota/pykotadmin.conf 
    6060        $ adduser lp pykota 
    6161          (this makes user 'lp' a member of group 'pykota') 
    62      
     62 
    6363    Another solution, needed on some systems : 
    64      
     64 
    6565        $ 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  
     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 
    7676    ensuring they can't read pykotadmin.conf with 'chmod 600 pykotadmin.conf' 
    7777    or simply allow everyone to read pykota.conf with 'chmod 644 pykota.conf' 
    78      
    79        
     78 
     79 
    8080  - Secure your database connections : 
    81    
     81 
    8282    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      
     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 
    8888    Keep in mind that if you use a centralized database, the first thing 
    8989    you may want to do is to restrict which hosts can access to it, i.e. 
    9090    only the print servers. 
    91    
     91 
    9292    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  
     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 
    9797      users, but you can change them later and and here's how to do : 
    98        
     98 
    9999      From the root shell do : 
    100        
     100 
    101101      $ su - postgres 
    102102      $ psql template1 
    … …  
    105105      template1=# \q 
    106106      $ exit 
    107        
     107 
    108108      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  
     109      database to PostgreSQL users 'pykotauser' and 'pykotaadmin' only, 
     110      and only if they connect from localhost and provide the correct 
    111111      password. Here's an excerpt from our own pg_hba.conf : 
    112          
    113         --- CUT ---         
     112 
     113        --- CUT --- 
    114114        local all    postgres                              ident sameuser 
    115115        local all    all                                   reject 
    … …  
    117117        host  pykota pykotaadmin 127.0.0.1 255.255.255.255 crypt 
    118118        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   
     119        --- CUT --- 
     120 
     121      As an alternative, which may depend on the default encryption setting 
    122122      used by your version of PostgreSQL, you may want to use the following 
    123123      settings instead : 
    124124 
    125         --- CUT ---         
     125        --- CUT --- 
    126126        local all    postgres                              ident sameuser 
    127127        local all    all                                   reject 
    … …  
    129129        host  pykota pykotaadmin 127.0.0.1 255.255.255.255 md5 
    130130        host  pykota all         127.0.0.1 255.255.255.255 reject 
    131         --- CUT ---         
    132          
     131        --- CUT --- 
     132 
    133133      Finally restart PostgreSQL so that the changes will be applied : 
    134        
     134 
    135135        $ /etc/init.d/postgresql restart 
    136          
     136 
    137137      Of course, depending on your needs, you may want to secure 
    138       your database connections in a completely different way or  
     138      your database connections in a completely different way or 
    139139      add other security layers on top of this. To do so please 
    140140      refer to PostgreSQL's documentation because this is out of 
    141141      the scope of the present document. 
    142        
     142 
    143143    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  
     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 
    148148      create two LDAP users which will be used for readonly and read+write 
    149149      access to PyKota's datas. PyKota currently doesn't do this, so 
    150150      you have to create an LDIF file this way (please adapt the 
    151151      DNs to your own environment) : 
    152        
    153         --- CUT ---       
     152 
     153        --- CUT --- 
    154154        dn: cn=pykotauser,dc=example,dc=com 
    155155        cn: pykotauser 
    … …  
    158158        description: PyKota ReadOnly User 
    159159        userPassword: {CRYPT}jfdsk653dsZFL 
    160          
     160 
    161161        dn: cn=pykotaadmin,dc=example,dc=com 
    162162        cn: pykotaadmin 
    … …  
    168168 
    169169      Then add these two users to your existing LDAP tree : 
    170        
     170 
    171171        $ ldapadd -W -x -D "cn=admin,dc=example,dc=com" -f users.ldif 
    172      
     172 
    173173      Now modify your LDAP server's configuration to respectively allow 
    174174      read+write and readonly access to the datas : 
    175        
     175 
    176176        --- CUT --- 
    177177        by dn="cn=pykotaadmin,dc=example,dc=com" write 
    … …  
    180180 
    181181      Finally restart your LDAP server so that the changes will be applied : 
    182        
     182 
    183183        $ /etc/init.d/slapd restart 
    184          
     184 
    185185      Of course, depending on your needs, you may want to secure 
    186       your database connections in a completely different way or  
     186      your database connections in a completely different way or 
    187187      add other security layers on top of this. To do so please 
    188       refer to your LDAP server's documentation because this is out  
     188      refer to your LDAP server's documentation because this is out 
    189189      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      
     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 
    216216    NB : In any case, the CGI scripts actually included in PyKota only 
    217217    do readonly accesses to PyKota's database. 
    218      
     218 
    219219====================================================================