It's time to stop chmod 777

[brian]

i'm not saying that the JED team have to surf and monitor but if it is reported to them then they place the warning notice on the extnesion.

Would it not make sense to just handle it like a VEL extension?

That would be my preferred option as it would mean that it would be removed from the JED whilst it was on the Vulnerable Extension List but I assumed that would be a step too far for some people so offered the lower level of maintaining the JED listing but with a warning.

[masterchief]

Would it not make sense to just handle it like a VEL extension?

That would be my preferred option as it would mean that it would be removed from the JED whilst it was on the Vulnerable Extension List but I assumed that would be a step too far for some people so offered the lower level of maintaining the JED listing but with a warning.

To my way of thinking, it either is or it isn't a security issue. If it is, streamline it into the existing process with appropriate community consultation. If it isn't a security issue, then no further action needs to be taken. The very subject of this thread would appear to indicate it's the former. If so, the next step is to hone the definition of the problem you are trying to stop in easily understood language.

[brian]

chmod 777 is a security issue

[shackbase]

Can you run a site without chmod 777 certain directories or files if you run apache as nobody?

Why not mix in some helpful hints on how to convert to suPHP for instance rather than `just saying you will go to hell if you don't believe me?

[derekbuntin]

I totally agree with you Brian!

Firstly, the host MUST setup the server properly, rem,ember you get what you pay for!

Secondly, the files, in our circumstance are set at 644, folders are 755 and there are many security issues that can be applied to both the site and the server to further improve security.

Derek

[amazeika]

Hello,

I'm not going to speak on behalf of all the developers out there, but more often than not, chmoding 0777 a directory (not the whole Joomla filesystem !) is a direct consequence of a poor server setup, i.e. mod_php on shared servers. After all, and for some extensions, PHP must have write access on some precise directories of these extensions.

No !, the Joomla FTP layer cannot do it all, for example, you have image processing through GD or Imagick, you cannot use the FTP layer for that. If PHP is running under www-data, nobody, etc. (the Apache user) the directory will have to be chmoded 0777 to let PHP write files in your Joomla filesystem (which is owned by a totally different user/group, the account's owner username/group). Changing the ownership to username:nobody and chmoding to 0775 would help a little, but again, on a shared server you would still be exposed, your neighbors also run PHP as the Apache user and would have write access to those folders.

You would be surprised to see how many shared hosting providers still use mod_php as their Apache PHP handler instead of using suPHP (php-cgi) or suEXEC (php-fgci).

My suggestion is, if you want security get a properly configured dedicated server. By having your websites on a shared environment you are exposed even if you use a correct set of permissions. If you can't afford a dedicated server, at least get a hosting account on a shared hosting provider that do not use mod_php, this will avoid all the permission problems that sometimes lead to chmoding some precise directories to 0777, but again, you are still exposed !.

Arunas

[brian]

Can you run a site without chmod 777 certain directories or files if you run apache as nobody?

Yes

[shackbase]

Can you run a site without chmod 777 certain directories or files if you run apache as nobody?

Yes

Really? How do you get around not being able to create files in directories that are not 777; uploading images for instance, and to edit files not set to 666; like the configuration.php file if you are running apache?

That seems next to impossible to me, but I'd love to learn how it can be done.

--Tone

[brian]

Please dont hijack this topic. Look up ownership not just permissions

[amazeika]

Really? How do you get around not being able to create files in directories that are not 777; uploading images for instance, and to edit files not set to 666; like the configuration.php file if you are running apache?

By using the Joomla framework (JFile classes, etc.). Of course, the administrator must have the FTP layer enabled and all your Joomla filesystem needs to be owned by the username/group of the FTP account the admin is using.

However, and like I said in my post, the FTP layer is not the answer to everything. If you use PHP libs that require write access to some directories/files, then you are out of luck.

Arunas

[nikosdion]

Arunas, you might want to read my post on this topic where I describe the only legitimate uses of 777 permissions, the gotchas and what you can do to make it secure. So, yes, on poorly configured servers with directories having the wrong ownership you get to this mess of using 777 permissions. That said, I strongly recommend users to use a PHP-based file manager, such as eXtplorer or ninjaXplorer, to create a temporary directory (or any other PHP-writable directory they might need) owned by the web server user, give it 0600 permissions and be done with it. Simple solutions work the best.

[brian]

So as you can see there is no need for 777 permissions and any and all extensions that either set permissions as 777 or recommend that you do are bad bad bad

[derekbuntin]

So as you can see there is no need for 777 permissions and any and all extensions that either set permissions as 777 or recommend that you do are bad bad bad

Agreed, security MUST be of up-most importance when developing third party apps!

[amazeika]

@nikosdion: I've already read your post . You are only proposing to change the the permissions dynamically and then reverting them back, which is a sad but effective workaround to the main issue, poorly configured servers. With your workaround, you still need to chmod 0777 !.

My point is that there are situations where you must chmod 0777 a directory. Like in my example, if PHP is running under nobody and your filesystem is owned by your account's username/group (setup using FTP layer) you won't be able to write images using for example GD (PHP image processing library) unless you grant nobody writing permissions in that directory, e.g. either you chmod 0777 the directory, add nobody in your group and chmod 0775 (I don't think hosting companies will agree to this) or change the group of the directory to nobody and chmod 0775. On the last two cases you are exposed in a shared server without having 0777 permissions in that directory.

So, yes, on poorly configured servers with directories having the wrong ownership you get to this mess of using 777 permissions.

This is not only an ownership problem, I'm talking about hosting companies that make bad decisions by using mod_php as their PHP Apache handler, the main cause of all this ownership/permission problem I presented in my previous post. Although I agree, and I've seen it myself in the Joomla forums, there are a lot of people suggesting to chmod 0777 as an effective way to solve problems.

In my opinion using mod_php all alone in a shared server environment represents a security issue all alone, regardless of the set of permissions you use. Choosing a properly configured shared server might be the best way to go.

@brian: So as you can see there is no need for 777 permissions and any and all extensions that either set permissions as 777 or recommend that you do are bad bad bad

I really hope that you are understanding what I'm saying, because I'm getting the impression that you don't . nikosdion proposed a workaround where you have still to make use of the chmod 0777, you just revert the permissions back to its original state.

I do not encourage 0777 permissions, instead I would suggest that people get their hosting accounts on properly configured servers, otherwise they might have to recur to workarounds regarding the ownership/permissions of the filesystem that may compromise their server, and this do not necessarily mean 0777 permissions.

I think that giving some guidelines for choosing a good web hosting provider to avoid all this permission mess due to a non-sense PHP/Apache configuration on shared environments might be a good solution to the main problem.

[brian]

You are completely missing the point that i am attempting to make that some extensions will automatically write files as 777 or instruct users in the documentation to 777 certain directories without even checking to see if 777 is "necessary" so even if you have "good hosting" the extension developer is making your site insecure

[nikosdion]

@amazeika I am sure that you read my posts, but I am not sure you've got the gist of them. In my first post I said that transparent chmod 0777 should be a LAST RESORT and ONLY applied TEMPORARILY, IF AND ONLY IF the host configuration sucks AND your user has screwed up his ownerships AND you need to APPEND to files, something that you can't do with any kind of FTP layer. So, no, if all you want is to write new files you should never, ever, EVER consider using 0777 permissions even temporarily! Even in the case of GD, you can always create the processed image in memory, then write it, for example, through JFile in order to use the FTP layer. Do not distort my words, I really know what I am talking about.

You can feel free to read my blog where I describe the proper server ownership and permissions configuration. If you do, you'll understand that I truly consider use of 0777 permissions unnecessary. Furthermore, as Brian said, the discussion is about extensions chmod'ing 0777 without asking. This is truly evil and should be banned.

[amazeika]

You are completely missing the point that i am attempting to make that some extensions will automatically write files as 777 or instruct users in the documentation to 777 certain directories without even checking to see if 777 is "necessary" so even if you have "good hosting" the extension developer is making your site insecure

Now I totally agree with you , which is not at all what you suggested here:

So as you can see there is no need for 777 permissions and any and all extensions that either set permissions as 777 or recommend that you do are bad bad bad

In your first post you asked:

What can we do to resolve this.

The issue is extremely complex and I know that my suggestion is far from being easy to achieve, i.e. educate Joomla admins to make a well funded decision when choosing their hosting provider. Therefore, and as long as these kind of hosting providers exist, people will face inevitable permission/ownership problems with some precise applications that will take them to make decisions that will compromise their sites.

Do not forget that this is mainly observed on shared environments, which are already UNSECURED by definition.

@nikosdion: you are correct, I misunderstood your comment about temporarily chmod and I'm not looking to distort anything, and I'm sure that you know what you are talking about, it was only a bad interpretation of what I read. I didn't like the temporary workaround at all .

You can feel free to read my blog where I describe the proper server ownership and permissions configuration. If you do, you'll understand that I truly consider use of 0777 permissions unnecessary.

Are you suggesting that I do not know to properly set ownerships/permissions ? . Of course 0777 is unnecessary !, I though I was clear on that ! .

In the case of GD, yes, I'm pretty much sure that you can indeed write the file via JFile, but I'm not sure that it will always be the case with any other PHP external library, probably yes. But you should also realize that instead of tackling the real problem, we are still looking for effective workarounds, which drives me mad of course !.

To conclude, deliberately chmoding 0777 should of course be condemned.

[brian]

To conclude, deliberately chmoding 0777 should of course be condemned.

Which was the purpose of the comments in the original post

[SodSy]

So each directory shoude set to 755

and file 644 ?

Am i right?

[mandville]

So each directory shoude set to 755
and file 644 ?
Am i right?

yes! http://docs.joomla.org/Security_Checklist_7

[bzcoder]

chmod 777 is a security issue

Not on my server. Your assuming. Your assuming a shared server scenario. With the cost of VPS these days, many of us have our own virtual "server"...

However, if someone has access to my server to the point where they can place files in a directory, then they have access to the point where they can read configuration.php which has the database user and password.

THAT is much more of a security risk than a folder with chmod 777.

I'd much rather see all the energy going into making component authors slightly more secure in a few situations instead go into making Joomla itself more secure by moving the all the files that don't need to be under the webroot outside the webroot AND by adding some basic configuration security.

[Tonie]

The end result doesn't matter, does it. Being able to write files, read configuration.php, etc. The end result is the same.

[brian]

I'm really happy that you have a secure vps and that no one can hack you and that you have the knowledge and skill to manage your server correctly.

Unfortunately the vast majority of joomla users do not have the skills etc and surely we as a joomla community have to help them in every way that we can to keep their joomla sites secure.

We can of course educate about the values of good hosting etc but even with that if we allow extensions to blindly chmod files and directories to 777 any amount of education is useless.

The only option is imho to list all and any extension that does this as a vulnerable extension.

[belownew]

We wouldn't expect a novice to do any of this... this is why Brian is saying the root issue is the extensions & we must make things transparent to the user/downloader.

We mustn't forget that a lot of people haven't got a clue about hosting or extensions - but mustn't be told to chmod 777 ever. They just go to JED, find the extension that does what they want & follow instructions - if they are told to chmod 777 a folder or file, they will without any knowledge of the possible consequences.

Okay you guys are the pros, but please hear the, "new lost one". As my user name states "below new" in Joomla Experience I chose my username accurately . I love Joomla, and enjoy "learning it" and have zero background until the day I signed up and asked a question about a week ago. I run a business but became so tired of getting hammered by "web pros" and wasted thousands of dollars. So the "motive" is "how hard can it be?"
And my experience states, it can be pretty darn hard. Since anything "unknown" appears hard. And it remains unknown, until it’s solved. So, "hindsight is 20/20."

You use terms that I have never heard of, you use chmod and I would read it and go “huh?” A Joomla Dictionary is needed to "understand" the answer if you get lucky and ask the question properly. So the price of "being new" I would venture to guess is the reason developers use or suggest 777. I know I shared this with my publisher and she was trying to update her site in Word Press and could not change a PHP file that a plug in said change, she was renaming, reloading etc.. she, like me, does not do this for a living. I told her “change the file permission” and then change it back in FTP and I just saved her a ton of time.


I can tell you what would be helpful, a program that “searched” my files for any “unprotected” or 777 type settings. Then, have it run a report saying “hey new guy..” this needs your attention.

You guys are “way smarter” then I will be, and a list of “who makes extensions” that are unsafe would be helpful to me. Or a big sign “enter at your own risk” would be okay.



Here is the catch, Joomla states "it’s easy" even a caveman can do it. "No coding" etc... And for most parts, that is "almost true."

[brian]

better than a program that scans your site for 777 is stopping developers being listed on the extension directory that would create the 777 in the first place.

[belownew]

how about a program that scans but needs the 777 to do it, I'm kidding. You seem very dedicated to "good" joomla and that is very obvious. And from the low man on the pole, I thank you for looking out for the things I have not learned yet, and will sadly find out after it is to late. I believe that is the main point. And the reason I backup daily, and security paranoid. So, this post is very insightful and helpful, since security is the most important element "IMHO."

[RussW]

The issue we have here, is that many Developers, may be great Developers[read coders], but are absolutely crap systems administrators. Of which, they need to be "Good-Above Average" Systems Administrators before releasing an Extension that has no idea how it is effecting the System it is living on. The next issue we have is that "Hosting Reselling", "VPS Servers" and "Dedicated Servers" are too easy to acquire without having to take an intelligence or knowledge test first. Hence, crap configurations and mis-understood ownerships and permissions are common-place.

If I applied for a job, I would need to qualify and fit specific criteria, but to write an extension or offer hosting, all I need is a keyboard and maybe a credit-card.



@bzcoder
Don't kid yourself....!
Give me a break [shaking-head], even on a VPS, 777 is a joke for security and "Best Practice" ...
Unless your box is powered-off, or you have a custom pseudo-World-Write protection tool, [which the rest of the hosting world would love to know about] then 777 means you are dead-in-the-water.....

[mandville]

[personal humour thought] when is someone going to make the "your server i not worthy for Joomla!" tool [/personal humour thought]
i think a lot of guidance to devs and some potential hosters has been raised here.
recommended reading (apart from the security checklist)
http://community.joomla.org/featured-ar ... -bits.html

[RussW]

Changing a users group membership is only useful for those with Shell Access and "root" access, of which 90% of the user don't.

This method also has it's downsides and is still only a work-around for a correctly configured server, unless the group being added to is an internal group only and has no access rights via application binaries or processes or the proc file-system, of which PHP and apache are not one of these.

[RussW]

@springsage
This really is not the place to request assistance, in future please try and post in the most appropriate forum and read the stickies and notices in those forums.

In the Security Forum there are many posts, stickies and references to checklists and tools to assist with discovery, resolution and recovery practices.