(Yes, I know that questions pertaining to lighttpd fit better on SF, but I thought it was more apt to be asked here since it's primarily concerned with security policy.)
We're planning to set up a small web server in my college, so that people could get some web space to put up web pages and the like. They could also upload PHP pages. The whole setup runs from within a chroot jail.
We are thinking about using the same infrastructure to put up some more services, for instance a discussion forum. My problem is, putting the forum in the same document root (or indeed, the same chrooted environment) pretty much allows any user to place small PHP scripts in their directories that can access the forum configuration files (using, say, file_get_contents). This is a massive security risk! Is there any way to solve this issue, short of disabling PHP for the user accounts, and only keeping it enabled for the discussion forum and the like, or serve the forum elsewhere and proxy it using lighttpd?
I doubt setting ownerships/permissions would do anything to fix this, since, the way I see it, the PHP FastCGI process is spawned by the web server, and hence, any page that can be accessed by the server (they all must be, seeing how it is the server that must ultimately serve them) can be accessed by the PHP scripts uploaded by a user.
Any help would be appreciated!
Well, a few points.
First off, while Lighttpd is GREAT for high performance needs, it was not designed to be used in a shared host setting. Apache would likely be the better choice for that, since it supports things like .htaccess...
Secondly, PHP does not need to be run as the same user as Lighttpd. You can use the spawn_fcgi program to launch each fastcgi listener as the user of that website. You would declare a fastcgi backend for each virtual host. Note, that you likely won't be able to use any of the built in vhost modules (simple_vhost, etc). Simply use the regular expression matching:
Either by IP and Port:
$SERVER["socket"] == "127.0.0.2:80" {
fastcgi.server = (
".php" => (
"username" => (
"socket" => "/tmp/user_php.fastcgi",
)
)
)
)
Or by host name:
$HTTP["host"] =~ "example\.com" {
# ...
}
You would likely need to modify the init script to also execute spawn_fcgi to launch the php processes for each user.
Each user needs to have its own Linux user account. Then you need to use SuPHP+LightHTTPD to make sure that the php code is run with the privileges of that user. Next you should make sure that all files are owned by the correct user and chmod 700 or chmod 500 (best for .php files). The last 2 zeros in the chmod, along with suphp makes it such that users cannot file_get_contents() each others files.
Related
So far my search has shown the potential security holes that will be made while trying to perform a sudo'd command from within PHP.
My current problem is that I need to run a bash script as sudo on my work web server via PHP's exec() function. We currently host a little less than 200 websites. The website that will be doing this is restricted to only be accessible from my office's IP address. Will this remove any potential security issues that come with any of the available solutions?
One of the ways is to add the apache user to the sudoers file, I assume this will apply to the entire server so will still pose an issue on all other websites.
Is there any solution that will not pose a security threat when used on a website that has access restricted to our office?
Thanks in advance.
Edit: A brief background
Here's a brief description of exactly what I'm trying to achieve. The company I work for develops websites for tourism related businesses, amongst other things. At the moment when creating a new website I would need to setup a hosting package which includes: creating the directory structure for the new site, creating an apache config file which is included into httpd.conf, adding a new FTP user, creating a new database for use with the website CMS to name a few.
At the moment I have a bash script on the server which creates the directory structure, adds user, creates apache config file and gracefully restarts apache. That's just one part, what I'm looking to do is use this shell script in a PHP script to automate the entire website generation process in an easy to use way, for other colleagues and just general efficiency.
You have at least 4 options:
Add the apache user to the sudoers file (and restrict it to run the one command!)
In this case some security hole in your php-apps may run the script too (if they can include the calling php for example - or even bypass the restriction to your ip by using another url that also calls the script, mod_rewrite)
Flag the script with the s bit
Dangerous, don't do it.
Run another web server that only binds to a local interface and is not accessible from outside
This is my prefered solution, since the link calling the php is accessible by links from your main webserver and the security can be handled seperately. You can even create a new user for this server. Some simple server does the job, there are server modules for python and perl for example. It is not even necessary, that you enable exec in your php installation at all!
Run a daemon (inotify for example, to watch file events) or cronjob that reads some file or db-entry and then runs the command
This may be too complex and has the disadvantage, that the daemon can not check which script has generated the entry.
I rule a server where several users have their own webdir, set on /home/user/public_html.
Nginx is running as http.
Everything works OK, but if a php requires a file to be created, it outputs a permission error.
How may I fix this?
Is possible to tell nginx to create all files under /home/username as "username"?
Regards && TIA ^^.
Yes, this is possible. Actually it's not Nginx, it's the FastCGI PHP module which is acting as a specific user. There is a good explanation of how to setup a Debian/Ubuntu system to do that.
Additionally I would create two users and one group per account (e.g. user1, user1-www and user1-group). For FTP you can use user1/user1-group. But the FastCGI PHP module can be configured to act as user1-www/user1-group.
Now you can limit read and write access to the folders of one account.
Your clients are free to allow or forbid write access to any file or directory based on their requirements.
If a PHP process can modify PHP code, you are exposed to be hacked and sites to be manipulated. Limiting write access to data files only reduces this danger. If you are on your own I wouldn't mind but providing hosting services to other people increased your responsibility.
this might seem like a stupid question but I've Googled to no avail.
I've always thought of PHP as a language for creating dynamic database driven sites, and I've never thought about using it to move system files on the actual server (as I have never had a need to). My question is:
can a standard PHP 5.3.x.x installation move, copy or edit system files (I'm using a Linux sever as an example) around in /bin or maybe /etc?
is this a good idea/practise?
It has never occurred to me that if a malicious hacker were to be able to inject some PHP into a site, that they would effectively be granted access to the entire Linux server (and all its system files). I have only ever thought of PHP as something that operates inside the /vhosts directory (perhaps naively).
Sorry if this sounds like a stupid question, but I can't really test my theory as if my boss was to see me writing/uploading/executing a script that moved stuff around in the Linux file system I would be dead.
Thanks for your help guys! :)
PHP can to your server whatever the permissions of the user account it runs as allow it to do. PHP as a language is not restricted in any way (at least, in terms of permissions), it is the user account that is restricted.
This is why people will usually create a user for Apache/nginx/insert web server here to run as, and only give it permissions to manipulate files and directories related to the web server. If you don't give this user access permissions to /bin or /etc, it's can't do anything that will affect them.
is this a good idea/practice?
Normally not. Leave system administration to your sysadmin and not the user requesting your PHP scripts.
PHP can attempt to call many system commands to move or directly edit files on the hard disk. Whether it succeeds depends on the security settings.
Let's assume your running PHP thru apache and apache is set up to run all processes as the user www-data - a default setup for OS's like Debian. If you give the user www-data permission to edit /etc then yes, PHP can read and write to files in /etc
There is only one major drawback as you identified; security, security and security. You also better be sure that your PHP works properly as 1 wrongly written file could now take down the entire server.
I would also definitely not practice on your server behind your bosses back. Look into getting a cheap virtual machine, either hosted elsewhere or on your own machine curtsey of VirtualBox
Yes it can. Its a programming language, it can do anything.
It completely depends who is running it. If its root it can do anything. If its just a normal user bob. It can not do much outside the home /home/bob. Apache is also like bob. Apache usually runs under www-data, www, apache user names.
Is there any way to make Apache to read PHP documents from RAM?
I'm thinking of creating a virtual disk in the memory and then modify httpd.conf to change the document root directory to the virtual disk in the memory.
Is this viable?
Basically, what I want to do is distribute my PHP code to my users' computers so they can run it. But I don't want them to be able to look at the PHP source code easily - the code can't be stored in the harddisk in plain text, instead, they are stored in a data file and then read by my program into the memory where Apache reads it.
Is this viable? Is it easy to create a virtual disk in memory in C++ yet the virtual disk can't be accessed by any other means such as My Computer?
Update:
Thank you all for the questions which would help me better percept my goals, but I think I know what I'm doing. Please just suggest any solutions you may have towarding my needs.
The hard part thus far is for Apache to read from somewhere other than a plain directory in the harddisk that contains all the source code of my project. I would like it to be as concealed as possible. I know a little about windows desktop development and thought virtual disk might be a solution but if you have better ones, please suggest.
You can, in theory, have Apache serve files out of a Samba share. You would need to configure the server to mount a specific file share made by the user. This won't work if the user is behind a firewall or NAT gateway of any variety.
This will be:
Slower than molasses in January ... in Alaska. Apache does a lot of stat calls on each request by default. This is going to add a lot of overhead before even finding the file, transferring it over, and then executing it.
Hard to configure. Adding mounts is a non-trivial task at the server level and Samba can be rather finicky on both sides. Further, if you are using RHEL/CentOS or any other distro running SELinux, you're going to have to do the chcon/setsebool tapdance to even get it working. The default settings expressly prohibit Apache from touching any file that came to the system through a Samba share.
A security nightmare. You will be allowing Apache to serve up files to anyone from a computer that is not under your direct control. The malicious possibilities are endless. This is a horrible idea that you should not seriously consider.
A safer-but-still-insane alternative might be available. FastCGI. The remote systems can run a FastCGI process and actually host and execute the code directly. Apache can be configured to pass PHP requests to the remote FastCGI process. This will still break if the users are firewalled or NATted. This will only be an acceptable solution if the user can actually run a FastCGI process and you don't mind the code actually executing on their system instead of the server.
This has the distinct advantage of the files not executing in the context of the server.
Perhaps I've entirely misunderstood -- are you asking for code to be run live from user's systems? Because I wrote this answer under that interpretation.
I just needed to know that is it possible in php to create an ftp user, and then create folders on the server and grant ftp access to selected folders for the ftp user created.
Thanks again!
Native PHP can not do this. The task is way out of PHP's scope.
Depending on the server OS and FTP server software used, however, PHP could call some shell scripts (or WMI / PowerShell scripts on Windows) that accomplish the task. This is not trivial to set up, though, especially not if it's to be done safely (without giving the PHP process root level privileges).
The question may be better suited on Serverfault.com.
There are a few web hosting panels written in PHP that crate ftp accounts among other things so it's definitely possible.
The exact procedure depends completely on the FTP server you use. It may involve creating new Unix user accounts.
This is more an FTP or operating system question than a PHP question though as you need to shell out to do the configuration. As Pekka said you may have more luck asking on Serverfault if you include the details of your setup.
No but if I'm not mistaking you could do something like this
Create a shell script (ftp.sh) that's has SUID (make sure it's owned by root and only can be read/written by root) that creates users, sets the permissions, etc
Call the script from php
system("./ftp.sh ".escapeshellarg($newUsername)." ".escapeshellarg($newPassword))
However I'm pretty sure there are more secure/correct ways of doing this. I can definitely see this becoming a security nightmare.
The answer is "Yes" if the web process where the script runs allows changes on the FTP settings e.g adding users, group etc. either by native PHP function or additional "Shell script" and it would be "No" if the web process doesn't have access nor privilege to make changes.