What's the best practice in a secure manner to setup the user/group and permissions? Here's what we currently have; web server runs as www/www. Fastcgi Php runs as www/www. User's shell/ftp account is username/username.
We want the user to be able to have full access to all files, including those created by the web server 'www' from the shell or ftp. Similarly, we want the scripts run by fastcgi/php to be able to create files in user created directories and modify user created files.
Best practice for multiple users with different domains / files would be running suexec for fastcgi, so they run their own files as their own user, and their scripts don't have the privileges the webserver has.
If you're paranoid you start chrooting.
Related
I am currently attempting to write a simple web page to store emails in a database. I am on a server which is not mine (but does run Apache), so I do not have root access, so I have opted to use SQLite3. The goal is to use PHP to INSERT into the database, however, I continue to encounter the issue with the database being owned by me and the PHP attempting to access using the user "apache" which leads to a "readonly" error. Since I am not root, I cannot chown the database file and even when I chmod 777, it has no effect. The conclusion I came to was to have the PHP script create the database itself (under the user apache) but now I do not have write access to the file. Is it okay for me to just allow apache to own the database or is there some better way to do this?
SQLite is a library, i.e., it's just a bunch of code that runs inside the web server process. This means that accesses to the database file behave just like any other file access from Apache.
The web server process needs to be able to access the file itself, and to create the journal rollback file in the same directory.
chmod 777 is a bad because every user on that machine can do anything to the database. It would be a better idea to have the database file and the directory belong to a group that has you and apache as members.
If the server's administrator will not create such a group, then you could have apache as the owner, and add a backdoor (sufficiently protected) to your web app to allow overwriting the database with a new file.
I'm creating a web app (php) that handles the creation of Drupal sites on a live server.
The system is able to create new sites and give some maintenance on existing ones. And, as this is a web-hosting environment, each folder may belong to a different user.
In order to do that properly I need to let the apache user run some commands as some other user.
What I do to create new files (and interact with git/drush/etc) is something similar to:
$some_command = `echo "PASSWD" | sudo -u USER -S do_something 2>&1; echo $?;`;
I already have a set of commands on the sudoers file that the apache user can run as the git user.
My issue now is that I need to let apache run as ANY user that may have a hosting account on the server.
My idea was to create a apache ALL=(ALL) ALL entry on the sudoers file. I would still leave all those commands asking for the users password.
With that in mind, is this wise to go with this approach? And if not, maybe I could apply the "allow all" policy only to the users that have a hosting account. If so, how do I narrow the policy to only one group?
Thanks
Edit: I though on using suPHP for this, as it allows apache to run each PHP script as its owner. But I would still need to run some other commands as another user (as creating files in someone else's home folder/public_html), so it seems that it isn't an option.
Based on our discussion in comments, I would advise installing something like suPHP so that each of your user's scripts are owned by their actual user and not Apache.
I figure you are having this issue is (maybe) because you want to be able to perform the administrative functions of other user's sites from a web interface. If you have a generic user like apache that other users can run scripts as, allowing that user automatic sudo permission is a bad idea since it could easily be exploited to gain unauthorized access.
To get around that, make sure you run your administrative functions as a special admin user that has permission to modify other people's files. Also make sure to chown any files you create as the appropriate user so they can read/write them. And as long as no other users can access that admin account or run PHP scripts as them, you should be much safer.
If you're running the admin functions from the console then it should be even easier, otherwise just set up a suPHP user to run your master functions from the web and use good credentials for the account.
Doing something like that will be more secure and should allow you to do everything you need without opening things up more than necessary.
The Config:
Webserver Apache 2.2 / mod_php 5.3 (FreeBSD 8)
User websites:
/home/user/public_html
Platform files
/usr/local/myPlatform/
The Premise:
Each vhost in the apache config has the platform directory aliased to /myPlatform so it can be accessed via hxxp://www.mysite.com/myPlatform - This is to keep the source of the platform system safe from be being stolen by a user.
The Problem:
The platform directory is 500 owned by the apache user. This is good and keeps the shell users from being able to view the files and still allows apache to read and exec the php files. However, one could conceivably create a PHP script (which runs as apache) to parse the directory listing, copy the files and give them as a zip download or something to the person. Obviously this obscure and more or less unlikely but still possible.
Is there any way to prevent this? IE blacklist that directory from fopen, shell, and shell_exec commands?
For that matter, is there a way to do this in such away that works for all server side scripting languages such as perl, in addition to php?
Possible to do this without suPHP or suExec?
Is it possible to run exec() as a a different user (on my box it runs as www-data). I wish to execute a script that needs access to files that are not owned by www-data.
If you have access to the server's configuration (assuming it's Apache), you might consider using suPHP. In a virtual host's configuration you can explicitly set the user and group for which a PHP script is executed:
<VirtualHost 192.168.1.1:80>
...
suPHP_UserGroup user group
...
</VirtualHost>
This setting is available for suPHP configurations built with the --with-setid-mode=paranoid option.
Another way to change the user ID would be posix_setuid() for which appropriate privileges are required. That would mean running your PHP scripts as root, which is a serios security issue.
I had a similar requirement some years ago that required a few PHP scripts to talk to a serial port. The first serial port is typically /dev/ttyS0, owned by root and in the group dialout.
For my initial setup, I added my apache user to the group dialout. The PHP scripts were able to directly talk to the serial port with no problem. However, only one instance of a script could open the serial port at any one time, so this solution could not work.
I then created a daemon that provided a layer between the serial port and the PHP scripts. The PHP scripts would talk to the daemon via a named pipe, and the daemon would then format the requests and pass it onto the serial port - doing a bit of caching along the way.
So, either add www-data, or whatever your apache user is, to the group that owns those files, giving group execution permissions, or use a proxy like I had. If security concerns you, then I'd go with the latter.
No, not directly. If you are on a linux machine and have the rights, you can set the set the setuid bit on your file.
Keep in mind that the webserver runs as a different user for a reason. It is a very important security mechanism and by working around it, you might cause a security vulnerability.
You can change the user under which your server runs. This can be easily done using the windows version of apache (apache runs there as service and it is easy to configure the user under which apache runs).
Which server plattform do you use?
How can you allow a PHP script to write to a file with high-security restrictions, such as only allowing a single user to write to it?
The difficulty seems to be that a PHP script is running as a low-permissions user (maybe apache, or www, or nobody?), and even if I chown apache the_writable_file, the directory it's in might not be writable for the low-level user. In general, what's the usual way that PHP can work with local files in a secure way?
Unfortunately, in shared hosts that use mod_php, there is no way to restrict access to secure files to your web app and login user.
The solution is to run your web app as your login user. When you do that, UNIX file permissions can correctly lock everyone else out. There are several ways to implement that, including SuExec, suPHP, or running PHP with FastCGI with mod_fcgid or mod_proxy_fcgid. FastCGI is my favorite way.
Another solution is to use a dedicated host or virtual private server.
Sure, chgrp apache the_writable_file and chmod g+w the_writable_file. After that, only your secure user and the apache user will be able to write to the file. Since the apache user is typically forbidden from logging in, you only have to worry about web users writing to your secure file using through the http daemon.
All the containing folders need to have execute permissions.
For example, if the file's in /foo/bar/the_writable_file, the directories "foo" and "bar" both need to have executable permission to access the_writable_file, even if they don't have read/write permission.