Security

The following notes are just for your information. Experienced administrators may use them to try to improve on the security. If you have a good idea, tell the authors!

This system is not Fort Knox and we assume that the users are not malicious. However, the best situation is when the webserver hosts next to the course only friendly (trustworthy) users. We collect here some positive and some problematic aspects.

Starting with PHP 4.2.0 the variable Register_Globals has been set to the value register_globals=Off as the default value in the initialization file /etc/php.ini. The installation and all scripts with now are compatible with both settings. Note that security is improved with this new default.

We one-way encrypt the course users passwords; the initial password is given during user installation but may be be changed by the user later on. Only the encrypted password enters the data base.

Whenever a user logs in a cookie is set. The lifetime of the cookie may be defined in the general variables file, however, usually one suggests at least several days (default: one year). This has the advantage, that the user does not have to login again for every access of the course. We assume single user configuration files at the respective user webbrowsers. The cookie is encrypted specifically such that another user may not fake it (except by stealing the cookie).

The data base password is in the file inc/general_variable_inc.php. It has to be readable by the web server. Thus on some installations it may be readable by other users (See comment on friendly co-users above. Extended ACLs may be helpful in this respect...)

The modules/filedepot/userspace/Filedepot has to be owned (rwx-permission) by the web server. Malicious co-users of the web server may trick the server to manipulate files and folders according to their wishes. Therefore in the file modules/filedepot/userspace/Filedepot/localinc/filedepot_vars.inc.php a list of forbidden filetypes (in particular php, php3 and php4) has been introduced. Upload of such files, as well as copying, renaming and unzipping to such filetypes is forbidden and the files will not be created. Depending on the webserver configuration the course administrator may want to add further extensions to the list (like cgi)

One could tighten the security by giving the rx-permission (better: ownership) of the further folders of the course (in particular the folders install, scripts, admin and inc) to the web server alone. This would hinder the lecturer at the beginning, but once the course parameters are not changed anymore, it should not be too big a burden. Such a solution may be feasible if the course owner owns the web server.

Note: The files within the users' filedepot are owned by the webserver and can be called directly from the "outside" by using the correct URLs. They are not limited to access for administrator or course users only. This appears to be no problem - but the users should be made aware.

So the security and protection of e.g. files in the Filedepot is limited. On the other hand, an e-education platform is no place to deposit sensitive and confidential data.