Important Security Question

ruud · 2008-03-22 21:59:25

If you’re willing to learn and have questions on a subject as important as security… don’t worry about our patience. It’s more than worth spending time to explain :)

Since cpanel didn’t let you see who owned the files and directories, I suggested using an FTP client or to log in using SSH (=Secure Shell, the secure followup to telnet). It would enable you to see the file ownership and permissions, as shown in the opening post of this topic.

I can think of three different hosting setups, when looking just at the username used when executing PHP scripts (like textpattern) and the username used by the webserver to serve static files (like images).

Let’s assume a user account named ruud, which you use for logging in (for example when uploading files through FTP). And if the webserver itself runs under a different username, let’s assume that’s www-data.

Note that the following is important mostly for shared hosting environments. If you’re on a dedicated server or on a VPS (virtual private server) where your files are completely shielded/separated from other users hosting other domains, then this doesn’t apply to you.

1. scripts and files both executed/served by username ruud

Probably not a very common setup in shared hosting environments. It’s safe because you can set permissions that allow nobody else to even read, let alone write/delete/create your files.

In this case, having 700 permissions would suffice for the directory, because everything concerning these files in that directory (creating them, reading them) is done by the same user, so only the user who owns the directories/files needs permission. The 7 means that the user who owns the directory can do anything with it: execute (1) + write (2) + read (4) = 7. You need execute permission on a directory to access anything in it.
The actual files in the directory could have 600 permissions, because the images are not programs and need not be executed. You just have to be able to create/write (2) them and read (4) them: 2+4=6.

2. scripts are executed as ruud, but static files are read by the www-data.

I think this is quite common when you’re in a shared hosting environment. It’s safe because while others on the server may be able to read some of your static files, you can set permissions more strict for your scripts (disallowing all access) and others cannot alter your files or create new ones.

Since all the writing/creating (2) of files happens with the same user name ruud, you need only write permission for the file owner. But reading (4) the files must be enabled not just for the user (ruud) himself, but also for the webserver (www-data):

user: 2+4 = 6
webserver: 4

So the files themselves need 644 permissions.
The PHP files need only 600 permissions, because they are started by the user ruud, not www-data.

The directory containing the files needs at execute permission (1) for both the user and the webserver. Only the user needs permission to write (2) new files or delete them. And if there’s a need to read the contents of the directory, then read (4) permission is needed as well.
Therefore the directory needs 711 or 755 permissions.

3. scripts and static files are both served under the webserver name ‘www-date’ for all hosted domains

If that’s how it works at your webhost. Don’t just consider switching, but run like hell to a webhost that knows what it’s doing. This is terribly insecure.

When both scripts and static files can be served by the same user (www-data) that can also access all the files on all the other domains on that same shared webserver, scripts from another domain on that server can read/write to directories that contain files for your domain, changing your stuff, installing malware, trojans and things like that.

Since you’re still uploading textpattern files to that server under your own user name ‘ruud’, the webserver can’t access it, because it runs onder a different username. Both for scripts and static files. So you have to grant permission to enable www-data to read/write files and directories owned by ‘ruud’, which means 777 for directories and 666 for files for this setup to work.

This is why a requirement to set 777 permissions should ring the alarm bells if you’re concerned about security.

Last edited by ruud (2008-03-22 22:01:58)

redbot · 2008-03-24 00:08:23

Thanks ruud! As always your explanations are very clear and exhaustive.
I just need some time to study it well now. I’m sure it will be very useful (not only) for me.

masa · 2008-03-24 01:14:42

ruud wrote:

You need at least execute permission on a parent directory to be able to access the child directory, so if the parent is set to 700, then only the owner of that directory can access the parent directory…. but if that’s true, then it’s pointless to make set the child directory to 777.

Ruud, if I understand your statement correctly everything should be fine as long as the web root directory is set to 755, meaning a child’s permissions can’t override the parent’s?!

The reason I’m asking is on Textdrive the settings are…

web root 755
images, files 755

but on another host they are…

web root 755
images, files 777

If I set images & files to 755 in the latter case, Txp diagnostics complains about them not being writable.

redbot · 2008-03-24 02:22:53

masa wrote

but on another host they are…
web root 755
images, files 777

masa, ruud
this is exactly my situation, plus all files are cmodded 644 and all directories inside the web root (except “images” and “files”) are 755.

Last edited by redbot (2008-03-24 02:51:23)

masa · 2008-03-24 02:39:47

redbot wrote:

masa, ruud
this is exactly my situation, plus all files are cmodded 644

Same here – is that save or not?

ruud · 2008-03-24 12:50:40

Files with 644 permissions and for 755 for directories is okay.
But needing 777 permissions for the directories to make them writable, that is definitely NOT okay. If that’s on a shared webhost, consult the tech support and ask them if it’s safe to set permission to 777.

masa · 2008-03-24 13:24:14

Ruud,

I understand that. Rather my question was, if the parent is set to 755 does setting a child to 777 override the privileges of the parent?

From what you said earlier…

…so if the parent is set to 700, then only the owner of that directory can access the parent directory…. but if that’s true, then it’s pointless to make set the child directory to 777.

…it sounded like it wouldn’t have any effect?!

ruud · 2008-03-24 14:27:04

A 777 child directory inside a 755 parent directory would work, but as I said before: please assume that 777 is not safe unless your webhost explicitly approves it.

rloaderro · 2008-03-24 14:33:44

Since, no one has mentioned it before – what about 775? Not as safe as 755, not as vulnerable as 777? Anyway it was as secure as I was able to go on a shared host since 755 didn’t work…

MattD · 2008-03-24 14:36:56

My host recommends 755 but textpattern still complains
Image directory is not writable
File directory path is not writable

masa · 2008-03-24 14:39:38

OK, thanks. I’ll have a chat with them.

Dragondz · 2008-03-24 15:28:54

I have also the same pb with an old host, but dont forget that 777 says: anyone can write on the directory, but the anyone (user can be a process) must have access to the system (username, password)! or am i wrong?

ruud · 2008-03-24 16:03:25

775 is probably as unsafe as 777.
Or to phrase it differently: if your scripts are not executed by your own user name (but instead by a generic web server process user like www, www-data or nobody), causing the created files (image/file uploads) to be owned by someone else than your own user name, then you’re should be worried if you’re on a shared hosting server.

anyone can write on the directory, but the anyone (user can be a process) must have access to the system (username, password)! or am i wrong?

True. However, when using 777 permissions it just requires one vulnerable script in any of the hosted domains, to mess with all the other domains hosted on that same server, while with 755 (or lower) only the vulnerable domain is affected.

zero · 2008-03-25 18:42:39

I use Filezilla but it doesn’t show the owner by default. I discovered you have to choose Edit | Settings | Interface Settings | Remote File List and you can select to show Owner/Group

redbot · 2008-03-27 23:35:33

ruud wrote:

…If that’s on a shared webhost, consult the tech support and ask them if it’s safe to set permission to 777.

I’ve asked my host.
They said that – though is always prefearable not to use 777 – I’m still allowed to do it.
They warned me to always use updated software to prevent possible code vulnerabilities
because the problem could be only caused by a script I’m running on my site .
Anyway – they said – they’re doing their best to ensure security (mod_security, firewall…).

So, ruud, what you think about their answer? Does it sound reliable or should I change host (which I hope to avoid if not strictly necessary)?
Thanks

Textpattern CMS

Textpattern CMS support forum

#16 2008-03-22 21:59:25

Re: Important Security Question

1. scripts and files both executed/served by username ruud

2. scripts are executed as ruud, but static files are read by the www-data.

3. scripts and static files are both served under the webserver name ‘www-date’ for all hosted domains

#17 2008-03-24 00:08:23

Re: Important Security Question

#18 2008-03-24 01:14:42

Re: Important Security Question

#19 2008-03-24 02:22:53

Re: Important Security Question

#20 2008-03-24 02:39:47

Re: Important Security Question

#21 2008-03-24 12:50:40

Re: Important Security Question

#22 2008-03-24 13:24:14

Re: Important Security Question

#23 2008-03-24 14:27:04

Re: Important Security Question

#24 2008-03-24 14:33:44

Re: Important Security Question

#25 2008-03-24 14:36:56

Re: Important Security Question

#26 2008-03-24 14:39:38

Re: Important Security Question

#27 2008-03-24 15:28:54

Re: Important Security Question

#28 2008-03-24 16:03:25

Re: Important Security Question

#29 2008-03-25 18:42:39

Re: Important Security Question

#30 2008-03-27 23:35:33

Re: Important Security Question

Board footer