symbolic link permissions warning

Howdy -- no, it won't break all Virtual Servers. It tries very hard to keep everything working as it does today :-)

The only potential problem, is that Virtual Servers that are relying on symbolic links could break. Which is rare, and you would have had to manually set it up to do so.

The security problem it describes is serious though, and we'd highly recommend performing the fixes.

However, if you happen to trust all the users on your server, and you don't have data that's considered private, then it may not be as big a deal in your case.

A summary of changes is --

It reviews your Apache config, and changes any references to "FollowSymlinks" to "SymLinksIfOwnerMatch".

It also changes the "AllowOverride" line to read:

AllowOverride Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch

It adds this to each Virtual Server:

php_admin_value engine Off

It'll also looks through your .htaccess files (with your permission), and changes "FollowSymlinks" to "SymLinksIfOwnerMatch".

apologies! please ignore. I posted in the wrong topic.

@eric I don't see 3.97 at http://software.virtualmin.com/gpl/universal/?

Was that domain using mod_php execution mode already? If so, you don't need to add that line, and virtualmin wouldn't add it either.

Hi there,

You say that - It also changes the "AllowOverride" line to read:

AllowOverride Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch

On our box when creating a new domain it looks like this:

AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch

Which one is right?

Regards, Leffe

My apologies, it should indeed contain the "All", as yours did.

We don't have a script that can undo the changes; our recommendation would be to generate a backup prior to making the changes, and if you run into problems, you can restore the backups.

However, the changes made are all fairly straight forward, and if there do happen to be any issues, they should be fairly simple to fix or work around.

Feel free to post about any issues you see, and we'd be happy to help.

Was the Zencart site not working anymore with the modified AllowOverride directive?

The change made by the fix script would have added the "Options" part, actually relaxing the override restrictions. Reverting to the previous state would once again forbid all override directives, thus actually improving security. :)

If the fix script actually added that Options part to an AllowOverride, which previously contained "None", it looks like a bug to me though.

I use lot's of symbolic links on my VPS setups, however since all the websites on them belong to myself, it is completely ok for me to have the old way. I'd like to revert changes described in #3, but I wonder if they will be overwritten again with next Virtualmin upgrade. How can I revert changes to old way once and forever?

it is completely ok for me to have the old way

I'm reluctant to use the prase "it's completely okay" when it's a security exploit we're talking about :-)

But, if your data in /home is not private -- any account on the system is allowed to see it -- and knowing that if someone broke into one of your accounts, they'd have access to most of the data in /home -- if that's okay, then the benefit of performing the security fix is minimal :-)

To prevent it from prompting you regarding that in the future, add this line:

allow_symlinks=1

to this file:

/etc/webmin/virtual-server/config

Thanks for the advice, going to make this change right away. Hopefully the future upgrades will not make me to revert all these changes back again.

so all the domains on my server are either static html sites or joomla or wordpress....will those site break if i click the fix button?

thanks

@warren: It's unlikely they will. But to be safe, simply take a backup of all domains before applying the fix. Doing so regularly isn't a bad idea in any case. :)

I mostly work with Drupal websites hosted on Virtualmin server, and am little bit concerned with this security change, since per http://drupal.org/node/1722250 it is recommended:

set FollowSymLinks everywhere and never set SymLinksIfOwnerMatch

It would seem to me that the Drupal guys doesn't overly care about security, if they instruct users to apply the insecure FollowSymlinks everywhere.

They should be made aware of this potentially serious issue and make their software work with SymlinksIfOwnerMatch.

The section on their site which mentions that is called "Google Pagespeed and yahoo YSlow suggestions".

Those are purely speed related suggestions.

Using SymLinksIfOwnerMatch does require an additional system call during the web request.

It's very unlikely on anything but the busiest of sites, that you'd notice a speed difference between SymLinksIfOwnerMatch and FollowSymlinks.

If you're that concerned, enable SymLinksIfOwnerMatch for a site on a test server somewhere, and do some benchmarking.

But sometimes, the cost of security means having the CPU do more a little more work to make sure things are safe :-)

You could always just enable some caching in Drupal (perhaps using memcache) to improve the website performance.

You do have two choices though --

1. You can use SymLinksIfOwnerMatch, and have it perform that extra system call, and you can rest well at night knowing your system is secure :-)

2. You can keep FollowSymlinks as it is now, with the understanding that any data you have in /home is vulnerable to this particular vulnerability. If you're the only user of your server, that may not be a big deal to you.

It's up to you which you choose, but SymLinksIfOwnerMatch is necessary if the security of your data in /home is important to you.

just a quick update....i ran the symbolic link fix and had no issues at all with any of the sites including the wordpress and joomla sites.

merry christmas everybody and thanks!

Argh! this has broken access to /webmail and /cacti aliases on my domains - now it just wants to download the php files! how do I fix this???

We aren't familiar with how your /webmail and /cacti aliases are setup -- can you show us the configuration used to make that work?

/etc/apache2/conf.d# cat cacti.conf Alias /cacti /usr/share/cacti/site

Options +FollowSymLinks AllowOverride All order allow,deny allow from all

    AddType application/x-httpd-php .php

    <IfModule mod_php5.c>
            php_flag magic_quotes_gpc Off
            php_flag short_open_tag On
            php_flag register_globals Off
            php_flag register_argc_argv On
            php_flag track_vars On
            # this setting is necessary for some locales
            php_value mbstring.func_overload 0
            php_value include_path .
    </IfModule>

    DirectoryIndex index.php

/etc/apache2/sites-available#: cat sites-available/default Alias /webmail /home/squirrelmail

Thanks for your configuration details! Unfortunately, it looks like the setup you have there is one of the ones that has been disabled due to security issues.

That is, it looks like Cacti is trying to use mod_php, but your Virtual Server(s) are likely configured to use FCGID or CGI.

The problem is that using the configuration you have above enables a security hole where a user can see any file in /home, regardless of their permissions. And that's not good :-)

You do have a few choices --

1. The best thing to do would be to place Cacti's web files into a specific Virtual Server, and access that Virtual Server, rather than using an alias that points to a shared location. We highly recommend serving files out of /home, where possible.

2. If you're okay with that security vulnerability existing on your system, you could instead undo the security change that were put into place. You can do that by editing your Apache VirtualHost block for this particular domain, commenting out the line that reads "php_admin_value engine Off", and then restart Apache.

3. A slightly better alternative to #2 above (but still retains the security vulnerability) would be to explicitly change your Virtual Server(s) to use mod_php. You can do that by going into Server Configuration -> Website Options, and change the PHP Execution Mode to be "mod_php".

I only need to make an alias to /webmail to /home/squirrelmail. I dont want to have to install squirrelmail into every users public_html folder.

Is there an easy way to do this without having to go through a massive debacle?

Cacti can wait.

Sorry, there are problems with that setup too... although in this case it is indeed serving files out of /home, it's still relying on the security vulnerability to do it, by serving files outside of a user's DocumentRoot.

Our recommended way of providing a centralized Squirrelmail (or Roundcube) webmail setup is to perform the Squirrelmail installation into one central domain (such as, squirrelmail.example.com), and then to configure webmail.domain.tld for all Virtual Servers on your system to redirect to that central squirrelmail.example.com installation.

Doing that avoids any of the mod_php or symlink-based security vulnerabilities that allow users to be able to access any file in /home.

If you'd like help configuring the webmail redirects so that they'll work as described above, let us know and we can assist you in doing that. It should only take a few minutes to complete (it's a Virtualmin config tweak, followed by a few commands on the command line, which we can give you).

Alternatively, you can reverse the security fixes as described in option #2 or #3 in my above comment. That will enable both Squirrelmail and Cacti again, but the security vulnerabilities will be present on your system afterwards.

I got these same warnings (symbolic links and mod_php) and we chose not to fix them. So we pressed the button that wanted us to ignore the warnings. Just before this, like a week ago, we added two new virtual servers and didn't upload any data to those virtual servers' domains. But after the ignore of the warnings, when we uploaded the website data (wordpress), the PHP code showed in the browser. All other domains worked fine though.

Thanks to Todd Schafer at post #5, I was able to comment php_admin_value and these two domains got back to normal.

I haven't upgraded yet.

My server is only hosting sites for my clients that I create the site for and I am the only one who does anything in the control panel with the exception of creating new email accounts. They don't have ssh or even ftp access.

Most of the sites are all using a centralized framework, such as zend framework.

I have zend framework installed in /home/zend, which is just a dir I manually created and owned by root.

Several sites just have a symlink to the /home/zend install so I only have to maintain one framework in one place. I have been worried that this setup will not work if I am understanding this change, which is why I haven't tried it yet. Is that correct?

Yeah, if /home/zend contains a set of PHP files, and something in the Virtual Server owner's homedir symlinks to that directory, that may indeed be a problem.

You'd need to weigh the security implications; it's not just a matter of the domain owner being able to access data in /home... that also means anyone who manages to break into the web app could do the same thing.

But if you feel the risk there is minimal, than it may be okay to not implementing the security fix now. In that case, you could hold off on doing it immediately, and slowly work towards a different setup for the future.

Ok. It may not be a problem in my case, which is probably unique.

99% of the domains on my server (about 150 now) are owned by the same company, which is a national real estate firm.

They have their main national site, but then also have a separate site for each agent. All of those agent sites work off of a single codebase (in the /home/zend dir) and only pull data from the main site's db. When creating one of these sites, it just copies a skel dir into the public_html dir, which is just a bunch of symlinks to the /home/zend dir, so it's super easy to set one up and maintain them all with one codebase. So basically if there was a security issue with an individual site they would already have access to all of the other sites data with very few exceptions.

Although, I'm not seeing a good solution in order to use the new security feature unless I didn't symlink anything and physically copied the whole codebase, currently in the /home/zend dir, into each sites dir. But then when I update the codebase, I'd have to manually update all of the sites that use it which would really slow production down and we are adding about 20 new agent sites/month.

Do you have any suggestions or is what I stated above the only solution?

One way around it would be to do as you described -- have an installation of Zend for each domain.

And then, what you could do is build a script to handle performing the update for you... that script could copy the new Zend version into each domain that needs it.

Another alternative... and an area where it gets tricky to explain, is that only some shared directories are a problem :-)

The security update makes it so that traversing a symlink using Apache will only work if the owner of the symlink, and the directory it points to, are the same.

But, that doesn't mean PHP can't use a shared directory for it's libraries.

If a shared directory is world readable, anyone can use it if the app is configured to make use of it.

If you either point your app at /home/zend, or configure PHP's include_path to use /home/zend, rather than relying on a symlink, you should be able to continue using a shared directory.

It would seem to me that the Drupal guys doesn't overly care about security, if they instruct users to apply the insecure FollowSymlinks everywhere.

They should be made aware of this potentially serious issue and make their software work with SymlinksIfOwnerMatch.

Related discussion at https://www.drupal.org/node/1269780

Locutus :) In June 2015 the Drupal security team has reviewed more closely this issue. Their assessment is in the comment titled "Drupal security team assessment" at http://www.virtualmin.com/node/24753#comment-150202

Good news for all using Drupal. A patch has been committed/pushed at https://www.drupal.org/node/1269780#comment-10547126

This means that issue will be fixed in the next Drupal version 8 release. Yayaya :)

Congratulations and thanks to all the volunteer contributors for their efforts

As for Drupal 7 and 6. A back-port of that patch was submit for review. Any volunteers to review and test it? Read more at https://www.drupal.org/node/1269780#comment-10548660