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

Currently, on all our Virtualmin servers all the files and directories within the document roots are owned by the website user (FastCGI mode), however Backdrop developer Nathan Haug says the following on https://github.com/backdrop/backdrop-issues/issues/395#issuecomment-6046...

Having files be owned by the web user is considered a security threat because it means the web user could access and write to other files in the user's home directory, such as the .ssh directory to easily grant an attacker shell access to the site. Again, it's all mitigating precautions at that point, if an attacker can execute PHP code, the game is already over.

Can we hear what Virtualmin developers say on this as we really need to have clear picture what is secure and what is not and what way should be we heading to? Thanks!

Status: 
Active

Comments

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.

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.

Jamie, I believe you and can confirm we've been running Virtualmin servers on hundreds of virtual servers (websites) and have not experienced any security breaches so far. However, it is little bit confusing to decide what would be the most correct policy to follow in posterity as Backdrop developer Nathan asserts:

So in the short term, if it's possible to set your servers up with a different user running PHP than the user who owns the Backdrop installation directory, that is the easiest and recommended solution. We might reduce the error level or allow it to be suppressed, but generally it is a good idea to set up a production site the recommended way.

I believe we have no other options for now, but to reduce the error level, however if setting virtual servers with different users running PHP than the virtual server's user is the ideal and most secure setup, then we would like to either (1) pursue Virtualmin officially starts supporting this method or (2) get your recommendation on how to automatize such custom setting.

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.

Hi Eric,

Some of your questions like "are all the users are trusted" are not relevant, because we are a hosting company and as such have to consider and be ready to all possible situations. Also we must provide the best possible and most secure configuration by default. Your party in its turn has to clearly understand that hosting companies rely on *min family of software and should avoid stances like "it doesn't sound like that's something Virtualmin is likely to support anytime soon" and be open to necessary changes, especially when hosting companies like us are requesting changes. Because we are just intermediary party which deliver Virtualmin-based servers to the end-users and they, the end-users, have to be using Virtualmin with absolute peace of mind. However, that's not the case when there are this kind of situations when yourself admit the current default settings are not ideal, but refuse to take necessary steps to make it perfect.

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

That's is really sad as we are relying on Virtualmin because many things (if not all) can be automated. Well, what is the exact difficult way - let it be manual, but we would like to set everything properly.

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.

Joe's picture
Submitted by Joe on Tue, 10/28/2014 - 21:19 Pro Licensee

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.

Eric and Joe,

Thank you for productive comments and leaving the door still open. I know your team is generally open to changes and can confirm that number of my own suggestions have already been accepted and implemented. I am just scared that such an important issue that potentially could bring to serious security troubles could get ignored. Please read what Greggles, a security expert guy from Drupal community, says on https://github.com/backdrop/backdrop-issues/issues/395#issuecomment-6070...

... Many tools like Cpanel and virtualmin are focused on the shared hosting market. In those environments they place a high priority on usability and containing any exploited sites to affecting only that one site. They frequently are configured by default so that the webserver user can write all files that run the site itself, but cannot write to files running someone else's site (e.g. using suphp). This solves the goal of containing exploits to one site, but is not a good setup for defense in depth within the one site itself.

We rely on Virtualmin not only on fraction of our customers on shared environment, but also on virtual private and dedicated servers.

Please also read Greggles further elaboration on the issue, maybe some of his ideas could be picked up and implemented in future and more secure version of Virtualmin:

My opinion is basically that it's OK to allow the webserver to write the files IF (and only if) the software running the site includes a self-update mechnism (perhaps that runs automatically). In that case you take an increased risk by not having good defense in depth but you get extra protection against all exploits because it's easier to follow rule #1 of security: run up to date software.

If I were building a hosting environment, I would look to build it using technology that automates the security for people or architect it in a way that you remove the problem. If the sites are hosted inside containers then they are separated from an exploit in one affecting another and you can set permissions inside that container so the site owner's FTP can read/write the files but not the webserver user. OR...if there were a button inside the hosting company's control panel that "secures file permissions" (for normal site usage) or "loosens file permissions" (for updates) then that could be handy.

Would appreciate if *min team could do anything about this issue.

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.

Jamie has commented in https://virtualmin.com/node/37105, so nevertheless this approach doesn't take care of the issue in FastCGI mode, we will be using, as you suggested, mod_php for now:

So, I will change Virtualmin in the next release to not fail domain validation if the public_html directory is owned by the Apache user. Virtualmin's existing support for running custom code after creation of a domain or installation of a script could then be used to set whatever permissions you want - once done, your users wouldn't have to perform any additional steps when installing scripts.