Securing your weblog - CGIWrap and SuEXEC
Co-authored by Arvind Satyanarayan and Elise Bauer
Tutorial cross posted on Movalog and Learning Movable Type
The installation instructions in the Movable Type Install Guide contain a section in the Configuration area called Enable Security Features. These instructions tell you to uncomment the Umask lines in your mt.cfg if your server is running cgiwrap or suexec. If you don't know what CGIwrap or suEXEC are, you may be tempted to skip this step. Don't. This step gives your MT installation extra security, which we will explain. (Note that this tutorial is only appropriate for MT installations on Linux/Apache web servers.)
What is CGIWrap or suEXEC?
CGIWrap and suEXEC are features installed by your web host that give extra security to your files in a shared server, or "virtual host", environment. Most Movable Type weblogs are hosted at commercial web hosts who are able to give their customers affordable server space by hosting the files of several customers on a shared server. In a shared server environment, CGIWrap and suEXEC allow your cgi files to be executed with you as the account "owner". The cgi scripts can then create files with more restrictive permissions (644) that keep others from editing your files, yet still allow you to edit them. Without CGIWrap or suEXEC, cgi scripts create html files that need to have more relaxed permissions (666) so that the account owner can manage those files.
Movable Type and CGIWrap/suEXEC
By default, the Movable Type cgi scripts generate files with permissions of 666 - read and write permissions for Owner, Group, World. (See FTP, File Formats, and Permissions.) In other words, everyone on a shared server can see and edit the files. This is the default because it allows for support for a wide range of server environments. For example, if you had your own dedicated server, it wouldn't necessarily matter that the permissions were set so broadly as you would be the only one accessing them. Another example is that some servers that use PHP require that PHP script permissions be set to 777.
Movable Type uses Umask settings to control the default permissions set on the files and directories it generates. "Umask" is another way of saying "File Mode Creation Mask". (To see how Umask works, see see this flash animation.) The default Umask settings are 0111, which set the default permissions of the MT generated pages to 666 and the MT generated directories to 777.
If you are running CGIWrap or suEXEC on your server, you can set the Umask settings so that only you, the owner of the MT generated files, have the permission BY DEFAULT to edit and change your MT generated files. This is why CGIWrap and suEXEC are so important. If you are on a shared server, anyone else with account privileges on the same server can edit your files with 666 permissions. Because CGIwrap and suEXEC allow your cgi files to be executed with you as the account "owner", you can now set permissions on your files to be a more restrictive 644 or 755 and you will be able to edit them because you are recognized as their owner.
Uncommenting the Umask Settings
If you uncomment (remove the #) the Umask settings in your mt.cfg file, the new settings will override the defaults and the new default permissions will be 644 and 755 for the files and directories. You should ONLY do this if you have CGIWrap or suEXEC on your server! If you do not have CGIWrap or suEXEC running on your server, and you are in a shared server environment, uncommenting these lines may prevent you from being able to edit any of your MT files.
Before uncommenting the Umask settings, make sure that your web host is running CGIWrap or suEXEC. You can run mt-check.cgi to find out. Just type the URL of your MT installation followed by mt-check.cgi, for example http://www.yourwebsite.com/path/to/mt/mt-check.cgi. If you are running CGIWrap or suEXEC, you will see the following line in your System Information:
(Probably) Running under cgiwrap or suexec
If mt-check.cgi reports that CGIWrap/suEXEC has been installed, then uncomment the following lines in mt.cfg
DBUmask 0022
HTMLUmask 0022
UploadUmask 0022
DirUmask 0022Additional Steps
If your MT install (the program files, not the weblog files) isn't in a cgi-bin folder but your host provides one you might consider moving your MT install into it; this will add extra security by preventing people viewing your mt.cfg from a web browser.
Another way to protect against web-based access to your mt.cfg file is to add a .htaccess file (see What is .htaccess?) in the same directory that holds your mt.cfg with the following lines:
<Files mt.cfg>
<Limit GET>
deny from all
</Limit>
</Files>If you are not using dynamic publishing, it is highly recommended that you set the permissions of your mt.cfg and mt-db-pass.cgi (for MySQL or other SQL database) to 600 for added security. Do not take this step if you use dynamic publishing.
Links: Apache suEXEC Support - notes on suEXEC from Apache.org
Special thanks to Brad Choate .
15 Comments
Leave a comment
Subscribe to Movalog's Feed
Ryan J. Bonnell said:
on Oct 4, 2004 8:30 AM | Reply
As a footnote to this article, you might mention that most webhosts that offer shared account hosting have stronger than normal account permissions to compensentate for the fact they're running in a less secure environment.
While most hosts might allow you to get a listing of the folders outside of your public_html area, they will not allow you to get a directory listing of any users' account that is not your own.
For example: On one of my shared hosting plans at (mt) Media Temple, I am allowed to get a listing of other user accounts (ls -al) in my /home directory, but I cannot see (or list) the contents of their respective directories.
So regardless of the umask settings their Movable Type installation is configured for, I still will be unable to view/modify/read/delete/ any of their files.
This behavior may not be true for all shared hosting environments, but this has been my experience with some of the best hosts out there.
However, where the umask, CGIWrap and SuEXEC settings would come into play, would be if you gave a different user (besides yourself) permission to access your home directory. Then the more restrictive permissions would be beneficial.
In any situation, consult your webhost if you have a shared hosting plan and don't know how the default permissions on your account are setup.
padawan said:
on Oct 4, 2004 5:20 PM | Reply
I would also advise to set the mask on both MT config file (mt.cfg) and the database password file (mt-db-pass.cgi) to something like 640 (which means user can read+write, group can read and anybody else cannot even read it). Otherwise you give away two important information: your database name and password.
Arvind Satyanarayan said:
on Oct 4, 2004 5:23 PM | Reply
There is code above that you add to the .htaccess in MTDIR, that prevents a web browser reading the file hence protects your mt.cfg from being viewed in a web browser.
padawan said:
on Oct 4, 2004 5:24 PM | Reply
Can you please explain why dynamic publishing prevents you to do that?
Arvind Satyanarayan said:
on Oct 4, 2004 5:26 PM | Reply
It is because PHP needs to be able to access mt.cfg and mt-db-pass.cgi to be able to do the dynamic templating. These files can still be protected by adding the code (decribed towards the end of the entry) into the .htaccess
Christine said:
on Oct 4, 2004 11:50 PM | Reply
While I agree that hosting companies are responsible for making sure that the servers are as secure as possible, it is also important that users make sure they have their file permissions set correctly. If your templates are set to permissions of 777, they are open to attack.
Ann said:
on Dec 16, 2004 5:29 PM | Reply
I had some trouble getting that mtview.php thingy to work. I had to amend the path, otherwise it would try to access that file in the root of my site, throwing up a 404 error. Then I had to change the permissions on the mtview.php file to 755, otherwise I get a 500 error (mine was world writeable before, and the server didn't like that).
Lisa said:
on Dec 30, 2005 8:16 PM | Reply
You may also want to point out that they should uncomment and change:
HTMLPerms and UploadPerms (0644 is way better than 777 or 666).
Angela said:
on Aug 20, 2006 10:30 PM | Reply
My site was recently attacked because I screwed up my permissions, so I'm starting from scratch now.
However, MT 3.3 doesn't have a mt.cfg file anymore, so I am assuming I need to add:
DBUmask 0022 HTMLUmask 0022 UploadUmask 0022 DirUmask 0022
to mt-config.cgi-original. That is the only place I can see that seems to make any sense, so I hope that's correct.
Arvind Satyanarayan said:
on Aug 21, 2006 8:03 AM | Reply
Hi Angela, with MT 3.31 you'll need to add those lines to mt-config.cgi (remember to remove the -original bit)
Ray said:
on Mar 14, 2007 3:26 AM | Reply
It would be nice if this item could be updated for MT3.34, with further discussion about HTMLPerms and UpLoadPerms and how they relate to the Umask settings.
I don't quite understand this, and it isn't well documented at SixApart. In fact, there are some things like adding an htaccess file to the MTDIR that seem to make so much sense one would think they should come out of the box that way. In fact, I'm surprised that the mt.config-original is so empty as shipped.
After reading this I am shocked to learn how unsecure my various personal and professional MT installs are. While discussing a recent hack on one of my sites with my host, they were unimpressed with the 777s on my folders. They referred to MT as a 'third party' application with the same sour tone one reserves for telemarketers.
Your item is the only thing I've found while searching for 'Secure MovableType', it would be comforting if its published date was newer than 2004. Anyway, thanks Arvind, this is illuminating.
Arvind Satyanarayan said:
on Mar 14, 2007 11:28 PM | Reply
Hi Ray, I just re-read the article and everything Elise and I discuss in this article remains applicable to MT 3.3x so you should be good using them.
WIth regards to why Six Apart doesn't provide some of this out of the box - I believe the answer is to increase compatibility. Especially when you're talking about permissions, different hosts allow/expect different permissions, especially for cgi/perl files in the cgi-bin.
Hope that helps!
Ray said:
on Mar 15, 2007 12:27 PM | Reply
The article helped, thankfully I'm familiar with both the old mt-cfg and the newer mt-config so I was able to grasp the details.
I'm satisfied now knowing that MT is setting folder perms to a more reasonable 755 and file perms to 644.
Of course, I had to delete my generated items and run a rebuild, but I'm on a small install so it was no sweat. Otherwise I'd have elected to change the existing perms in CPanel.
Is it necessary to add both htmlperms and upload perms to the config file in addition to the umask settings? I don't quite grasp the relationship between the two groups of config directives.
freecia said:
on Aug 18, 2007 1:01 AM | Reply
How do we reset these parameters in MT4? Thanks.
Arvind Satyanarayan replied to freecia's comment:
on Aug 19, 2007 3:19 PM | Reply
Hi freecia, I'm not sure what you mean by "reset" but all these instructions, I think, are still valid with Movable Type 4.