What I don't get is why most recommend 644 permissions on files and 755 on folders .... On a shared server (lets say a Hostgator etc) scripts or other files which could have database credentials and other info shouldn't be "world" readable right? So why is 644 recommended which gives global read access to files? How do you prevent other users on a shared server from viewing your scripts or other files? Can you not give access to the "world" user and still allow apache to be able to read a file? I know Apache needs to read files which is why read access has to be given but even if you use if you use SuPHP and (chmod files to 640 or even 600) but that just protects PHP files.. what about other file types that have to be in public_html eg xml files with db connections, .dat or other file types? Even .htaccess shouldn't be able to be world-readable but it seems like cPanel and others automatically provision it as 644? Any thoughts? How do you fully prevent home/user A from being able to view access home/user B file and folders? Is there such thing as complete isolation?
2 things to add. 1) Have you tried viewing a file in a browser that holds dbconnect info? It won't show if coded properly. Won't show in the source either. 2) If you try to view files which are owned by another user, so long as everything is properly set, you''ll receive Permission denied Editing with evidence root@server [/home]# su aaaaaa [/home]# cat /home/bbbbb/public_html/index.php cat: /home/bbbbb/public_html/index.php: Permission denied
I wish I knew the answer to your permission question. I've also been curious about that. This article goes into a bit of detail about it, but I'd still like to find out more. Even if you lock down the directories, exploits can be made by a user that can potentially let them read others files. Years ago, I was on a web host that gave everyone access to SSH, along with all the compilers and scripting tools on that system. I emailed them to ask how this was possible without having security issues. Their response was that they were using freeBSD jails and some custom stuff to isolate users from one another. I couldn't locate a good substitute to use on Linux, but I just noticed that the wiki article on freeBSD jails says FreeVPS is a similar application. I can't imagine that it would play well with cPanel though.
SecureCP, How did you get perm denied? Here's what I did: 1. logged in via SSH to one of our accounts... 2. Confirmed index.php is 644 and owned by the proper user ls -l index.php 3. Logged into another account on the same server via SSH 4. cat /home/user/path/to/index.php 5. Spits out all of index.php That is why 644 is completely insecure for files it seems... Yea you can block SSH access, use SuPHP set PHP files to 640 but what about other files with config or db connections XML etc that aren't PHP files... What about other non-php scripts that are uploaded to a server that are able to view other users files (since they are set as 644) and possibly pipe them into an email etc? So bottomline, I don't know why 644 would be secure for any file in a shared environment ...
Then your shell access isn't properly jailed. What OS are you running and what control panel are you running?
I know its not properly Jailed. Its /bin/bash i believe... It's actually a shared host I tested this on... not on our VPS's which are jailed shells.. But its not about shell, the thing is some user could upload some script (not via shell) use it to access 644 files on another users account since their files are world readable.... Examples are like: .xml , .htaccess, .htpasswd, .dat, .txt, .anything That's why I don't get why 644 is deemed appropriate and the usual default permission setting for files... 644 is almost as unsecure as 777 in that it still gives read access to the world user which can be just as detrimental as world write access..
Example user could upload and somehow execute a cgi, pl, php, Java, C or even some type of bash script with "cat" like functions that spit out contents of other users files into their accounts... In a shared environment where we have many different users with all different permissions set (depending on their level of responsibility/knowledge), I see this could be a big security risk... That's why I never understood why 644/755 is deemed as "safe" when 777 is always a big no no ... when even 644 can have almost the same security risk but with the ability for other hosting accounts to view others stuff.. So its like how can an administrator of a server prevent this? What do the large scale shared hosting providers do to provide ultimate security from User A being able to see User B's stuff?
/bin/bash shell access on the server shouldn't be enabled for accounts on the server. Whoever the owner of that server is, should read a manual, or figure out what they're doing so as to not put their clients in such a vulnerable position. I work for a large scale hosting company, and I assure you, other than on our vps's and dedicated servers where clients are in charge of shell access, each account cannot read the others' files. On that note, I'm going to drop out of this conversation because I can't seem to convey the idea properly and it seems that you have something against anything with 4 in it. Feel free to read more: http://en.wikipedia.org/wiki/Permissions
SecureCP, yea I agree with you on the /bin/bash I've talked to them about this and I don't know if they are going to change that.... I'm trying to have a honest debate here and I would like to have you involved since you specialize in cpanel security and maybe you and others can give us some insight. And look, maybe I shouldn't of used access via Shell as an example... Blocking access to Shell, PHP open_basedir are just work-arounds but the files themself are still "world" readable by any other user's script/process on the server ... From what I'm hearing its just not possible... I understand on a shared server there are always risks and possible , but just like one stays at a hotel, their room isn't accessible easily by another guest ( unless there's a break in obviously)... But the thing is "Read-only" permissions is like having a see-thru "glass door" on the outside of your hotel room... People can still see inside if they wanted too without "breaking in".. So isn't that a complete privacy/security breach? So my question which it seems rather reasonable which has to do with basic security ... is in general, how could your users files be truly secure if world readable permissions are allowed? Secondly, is there a way a server administrator truly isolate their shared accounts and all their files from read access via another user yet not system processes (apache, php, etc) .. Is there a way to get all files under one users ownership and still allow Apache to run them as usual? Doesn't make sense why in order for a server or its processes to run a file depend on user level permissions... Possible solution? It seems like Linux/Apache should create both "server process" permission sets and file access permissions... So that user's access of others files is independent of a servers access to those files.. What do you guys think?
Truly secure is 0750. If you are running a web server, run it under a different user, for example 'web'. And have all files owned by you with permissions 0750. This way server will never be able to modify the files. If the server needs write permissions, create a tmp directory and give it 0770.
I think these are truly secure file permissions (see below) or as secure as possible using SuPHP... Someone had originally recommended this in the cPanel forums.... I adjusted the below to be slightly different to have owner : owner for user/group (vs owner:nobody) for Non-Script Files, HTML, Images, etc and CGI/Perl Scripts. 755 (owner : owner) Folders 600 (owner : owner) PHP Scripts 400 (owner : owner) Configuration Files (config.php, etc) 600 (owner : owner) Script files requiring WRITE access 644 (owner : owner) Non-Script Files, HTML, Images, etc 755 (owner : owner) CGI/Perl Scripts Your thoughts? Is there a way to automatically set files to these permissions upon upload?