cancel
Showing results for 
Search instead for 
Did you mean: 

Security changes to crofters.force9.net

N/A

Security changes to crofters.force9.net

Concern over the security model on the crofters.force9.net server has been expressed in the CGI forum. For those of you who don't use crofters, this is the server that hosts the CGI-enabled webspace that Force9 customers can choose to activate. Two threads worth looking at are "Group and process ownership" http://portal.f9.net.uk/central/forums/viewtopic.php?t=1779 and "Very weak security" http://portal.f9.net.uk/central/forums/viewtopic.php?t=1316.

The problem is caused by the group membership and permission structure on the server. By default, these allow any user to browse and write to other user's directories. Users who are aware of the security holes can change the permissions on their directories and files to deny write access to other users, but they cannot deny all access without also denying access to the web server (httpd) process! (The web server process has to be able to read the files in order to make them available over the internet.)

The stop-gap solution of making the directory tree read-only is not perfect, either. Firstly, it still allows users access to other user's directories. Encrypted passwords in .htaccess files can then be subjected to brute-force attacks. Secondly, it means that CGI programs that need write access to the directory (e.g some wikis and simple forum scripts) cannot be used without giving every user write access to those files. (The files have to be set to be "world-writable.")

Various suggestions and solutions are discussed in the two threads above. Two options that are commonly used elsewhere are:


    1) A chroot jail for all users, restricting them to their own web root tree
    2) Changing the group structure of the server so that only the user and the httpd process can have write access to the user's directory.

The CGI service is a "value-added" service - not technically supported by Force9. Whilst the service is appreciated, I feel that the security model needs revising, for the reassurance of the customers, the integrity of the server and the reputation of Force9. IMHO, a chroot jail is the most preferable solution, however there are other possible solutions. Again IMHO, the security model should:


    1) Deny users of the crofters server the ability to view files in other user's directories.
    2) Allow the web server process to write to files without allowing other users to do so.

If you agree or disagree that the security on crofters.force9.net needs revising, please take a couple of seconds to vote in the poll.

Tony
6 REPLIES
Ianwild
Grafter
Posts: 3,835
Registered: 05-04-2007

Security changes to crofters.force9.net

Hi Tony,

There is not a technical solution to achieve any of the things you have suggested. I guess the simple option is to disable Shell access, at which point we could Chroot FTP.

I would be interested in whether this is something customers would go for?
N/A

Security changes to crofters.force9.net

Diasable shell access -- definitely not!
N/A

Security changes to crofters.force9.net

Quote
Diasable shell access -- definitely not!


Agreed!!

Ian, any reason why "2) Changing the group structure of the server so that only the user and the httpd process can have write access to the user's directory." could not work?

Neil
N/A

Further suggestions

Thank you for your reply Ian. I appreciate that you've taken the time to read and respond.

Although I do not know the exact configuration of your servers there, I think it unlikely that there is no technical solution whatsoever to the problem, rather solutions that you are not able or willing to implement.

I think its worth clarifying for all forum readers that the poll above is deliberately non-specific about the method, or consequences, of tightening security on Crofters. The Poll is just to register if you are unhappy with the current situation, not to vote on the implementation of any particular method to improve security. FWIW, I too would like to keep shell access to the server. This is especially useful when configuring dynamic web content and executing setup processes. For those people who use command line processes to backup their database, it is essential.

In your reply, you are probably referring to the limit in the stock Linux kernel of only allowing a given user to be a member of 32 groups. Crofters runs a Linux kernel, version 2.4.19-51um on i686 based hardware. This would be a problem when implementing the scheme of having the owner of the web server process, as, at the time of writing there were 3452 directories in the /home directory. Clearly making the owner of the web server process a member of every group would exceed the limit of 32 groups. However, there are patches for the Linux kernel available to increase this limit. A patch for the 2.6 series kernel is archived here: http://marc.theaimsgroup.com/?l=linux-kernel&m=106504416723659&w=2

Alternatively, It is possible to patch OpenSSH to offer chroot facilities. The project website is available at: http://chrootssh.sourceforge.net. Shell access would still be available using SSH clients. The loss of telnet access is acceptable, IMHO, given its weak security.

The CGI webspace appears be served by the Apache webserver. One tool that is supplied with the Apache source code is suEXEC, which allows scripts to be executed with the permissions of a given user. More information about suEXEC can be found here: http://httpd.apache.org/docs/suexec.html. Depending on the details of your Apache configuration, it may be possible to use this Apache helper to allow scripts to be run with the permissions of the owner of the directory, rather than as the actual owner of the web server process. This method would allow permissions to be tightened on the existing directories, at least preventing world writable permissions being necessary for wikis etc., whilst still allowing CGIs to write to a user's directory.

Once again, I'd like to iterate that I appreciate that Force9 offer this service to customers free of charge.

Tony
Ianwild
Grafter
Posts: 3,835
Registered: 05-04-2007

Security changes to crofters.force9.net

Hi,

I will take a look at the Chroot stuff for SSH certainly. This isn't my area of expertise, so it might help for me to be better educated, but I will pass on your suggestions tot he networks manager.

With regard to
Quote
"2) Changing the group structure of the server so that only the user and the httpd process can have write access to the user's directory." could not work?


Surely, if the webserver has write access to a users directory then that isn't solving the problem? It may mean you can't browse driectories, but it's only a line of PHP which you would need to execute to wirte anywhere where the webserver has write access?

Cheers,

Ian
N/A

Some more suggestions

Apologies for the delay in responding, I've been looking for solutions to the PHP issue you've suggested.

The Apache "perchild" module at http://httpd.apache.org/docs-2.0/mod/perchild.html allows daemon processes to be executed under a number of different UIDs. This software is in active development, but seems to be usable under Linux.

A more straight forward solution might be to use the "open_basedir" directive in the apache configuration. This can be used to restrict access by PHP scripts to a certain tree. For example, the following could be entered in each vhost definition:
php_admin_value open_basedir "/home/userhome:/www/userweb" 
with the necessary tweaks for the appropriate usernames etc. Creating a /tmp directory may be necessary for session handling.

An alternative "simple" solutions is the "safe_mode" is a possiblity. From the PHP manual:
Quote
When safe_mode is on, PHP checks to see if the owner of the current script matches the owner of the file to be operated on by a file function.
If that it not the case, an error is returned. There have been exploits found in this function in the past, so the latest verison of PHP is recommended. It is also important to prevent users from "chown"ing their scripts to the UID of other users on the system. The Crofters server seems to have certain restrictions of this nature in place already, but I have not tested it thoroughly.

A combination of one of the above solutions and a chrooted SSH environment might present an effective solution to the problem. (Unless there's something else I've not thought of! Smiley )

I hope this information helps,

Tony