Having files be owned by the web user is considered a security threat

Howdy -- yeah, if an attacker arrives at a point where they can run arbitrary commands on your server, and can edit files in $HOME/.ssh/, then they already could do nearly anything they wanted as whatever user PHP is running as.

Using FCGID and CGI, there isn't a way in Virtualmin to run as a user other than the Virtual Server owner.

Those implications are worse when using an alternative such as mod_php, as that would allow one Virtual Server owner to access files owned by other Virtual Server owners.

It may be possible to manually configure Apache to run PHP apps as a user within that Virtual Server that isn't the owner. That could be changed by modifying the SuexecUserGroup setting in Apache for a particular domain. You'd likely need to edit the permissions on the php5.cgi files in cgi-bin (or fcgi-bin) to match. I haven't tested that before though.

I'll talk to Joe and Jamie later this week regarding whether we'd consider supporting something like that officially, though it hasn't been on our radar in the past.

Yeah, I don't think that's something we would support.

The current Virtualmin method of running PHP and CGI scripts with the permissions of the domain owner is about as secure as possible. As Eric said, if the attacker modify arbitrary files and run arbitrary commands as whatever user PHP scripts run as, you've already lost.

From what Jamie's saying, it doesn't sound like that's something Virtualmin is likely to support anytime soon, unfortunately.

While it may be possible to set it up manually, there isn't a simple way to automate it.

Are all the users trusted on your server?

If all the users are trusted, and they freely share data between themselves, you could always use mod_php.

Using mod_php would mean the PHP apps would be running as Apache, rather than the Virtual Server owner.

However, if the users aren't trusted and don't share data among themselves, then that would be considered a security issue to enable that, since it would allow one user to read files owned by another user.

I do find that idea interesting though, and I'll talk to Joe and Jamie about that in more depth this week at our meeting. I can't make any promises, but maybe there's a way that we could allow advanced users to utilize such a feature. It wouldn't prevent someone from breaking into your system, and if a remote user can execute commands on the server, that's quite bad.

OTOH, such a feature could, perhaps, block some automated attacks who attempt to upload malicious files into the DocumentRoot.

Well, hearing that you're a hosting company is exactly the sort of thing I meant by my question... some people host what's considered "untrusted users" with Virtualmin, such as hosting companies.

Others only host a handful of sites from trusted users who all work for the same organization.

Your response answers my question perfectly -- for your situation, we would not recommend using mod_php. That would be insecure.

Regarding us being open to necessary changes -- we value your input, along with the input of other users of Virtualmin, and we're certainly open to changes in the product. At least, I'd like to think we are :-)

We're not saying we won't implement it, and in fact I was saying we're going to discuss that very thing at our meeting this week.

The problem is that such a feature would take time to test and implement, as it could have an effect on quite a number of things.

What you're suggesting is a large enough change that it's considered a big project, not a little one, since that's not how things work now. So if we decide to implement it, that's not something we could have out the door very quickly.

So we'll talk about your idea, and see what's plausible.

There may also be other ways to implement it that we haven't considered yet which may be easier to incorporate.

Since we haven't tried such a setup before, we don't have specific steps for you to follow to manually implement what you're requesting.

Off the top of my head, you would need to create a new user within the Virtual Server. And then, the SuexecUserGroup in the Apache config for that domain would need to be updated to use that user's UID and GID. Then, it may just be a matter of updating any CGI/FCGID scripts to use that UID and GID.

We're not ruling out this solution, or some other. We're discussing it. If there is a reasonable way to address this potential risk, we will. I'm not convinced another user account is the best or only way to solve it, but that may be because this isn't an issue I'd considered in the past (and, as Jamie and Eric have mentioned, if the attacker has the ability to execute arbitrary code, you've got trouble, regardless of the user, but running it as the domain owner account would be more dangerous than a special account that only had access to public_html and cgi-bin).

SELinux or mod_security might also have some mitigating features for this particular concern. Eric and I are doing some research between now and our company meeting on Thursday.

Sorry, while we haven't forgotten about your request, this isn't on the todo list for the near future.

If you need to do something along these lines, you could use mod_php, which Jamie is modifying to better handle the warnings you were seeing.

Tech savvy Virtual Server owners could also remove the write permission from files, and then temporarily re-add it when performing updates. At our next meeting, I'll talk to Joe and Jamie to see if there's a simple way to temporarily change permissions within Virtualmin, though I suspect that's much harder than it sounds since web apps typically need to write to some directories within it's DocumentRoot.