Hi all. I am tweaking my php.ini file and I do not understand the bolded text below...

http://phpsec.org/projects/phpsecinf...d_tmp_dir.html

Questions:
1.) What does the bolded text mean, and how do I do that?

**NOTE: I don't have VPS Root access, and am hoping this can be done using my regular account via SSH.

2.) Where would be a safe place to put these temporary files?

Sincerely,


Rob

It pretty much means what it says.

The upload_tmp_dir is something you don't want users accesses outside the PHP control due to possible corruption (the referenced race condition).

You don't want it accessible by general users thus it should not be /tmp (which does happen to be the default) as it could be a problem with file naming conflicts (which could cause corruption).

Putting it outside the document root prevents other accesses to the web server from gaining access to the files - which can also cause the corruption.

Now, if you don't have general users (other than say yourself), then using /tmp shouldn't be a problem (though you might have to check SELinux security controls on RH systems for httpd to have /tmp access, usually it is disabled).

Their suggestion of using "/var/www/foo.bar/sessions" would be outside the document root(normaly "html"), isn't /tmp, and normally inaccessible by users (usually blocked at /var/www to read only access). It does have to have proper ownership (it will be used by the web server for read/write operations). If you are on a RH system, it must also have the proper security label (the type must allow writing, I think it would "unconfined_ubject_r:httpd_sys_rw_content_t:s0", where the type is "httpd_sys_rw_content_t")

Normally, the httpd configuration would be set by the system administrator. If you can set that, then you should be able to set the rest. I am assuming you are running under a VM, and have root access to the VM, but not the host of the VM.

1 members found this post helpful.

But does that mean it has to be in a location that I can't create or access since I don't have Root access on my VPS?


Is there anything that is safe to place in "/tmp" ??


I'm not following you on this one - I think some words got mangled!

Also, what is "document root"? Is that what I call "Web Root" (i.e. "/public_html")?


My VPS runs CentOS 6. I don't have Root access. There is one VPS account called "rob123". (Of course my web host has "root" access to my VPS.)



That went over my head!


See above.


What I ended up doing was to create this new directory...
And I gave it 700 permission.

Is that okay?


Rob

Not having root on the machine means that you cannot configure the web server. And that makes it rather difficult, if not impossible, to meet the security requirements of the web server.
A directory. The problem is how the web server is configured. Normally it runs as an independent user to isolate it from other users. For you, not being root, means that you cannot create any directory that the web server can access that other users cannot also access.
It depends on the system the web server is running on. If it is RH based, then the web server is also running in a security compartment that prevents it from accessing anything that is not explicitly labelled for the web server to be accessed - even if that data is owned by the account the server is running under.
If you look at the configuration file for apache, there is a directive "RocumentRoot" that identifies what the web server uses as the base for URL interpretation. All URLs are interpreted to be within that directory tree, with the assumption that this is the only data the web server will provide.

There are additional directives such as UserDir that define access to other directories (specified by the path given) that allow the web server to access them - usually as "http://hostname/~user/...." but access to a directory owned by the user, MUST grant either world access or the user has to be in the same group the web server runs under and grants group access.

Neither of these allow (by default) the web server to actually WRITE data (security hazard). In RH systems, even if the web server has read/write, it cannot do either unless the security label grants permission.

And if there are multiple users on the system, then these OTHER users may also access these files.
This will be a problem meeting the requirements. CentOS IS a RH based system, and thus uses security labels unless it has been disabled.

You need to find out exactly what you are allowed to do - and none of it will encompass the security specifications of the package listed.

It assumes you are the system administrator trying to set up a secured web server.

I don't think it will help - no one but you will be able to access that directory, including the web server.

1 members found this post helpful.

That's a bummer. (I thought I was doing pretty well until now.)


You keep saying "other users". Who ae they?

The only person on my VPS is me (i.e. "/home/rob123/")


Guess that means I have to spend more money that I don't have to pay advanced support to do this for me...


Lovely.


Rob

Have no idea - at a minimum though, is root.
And whoever configures the web server, and maintains the security of the system.
Usually, it means you use the system as THEY defined your support to be. And that appears to exclude control over the web server.

So here is the link from my OP...

http://phpsec.org/projects/phpsecinf...d_tmp_dir.html

Your comment above implies I should follow how my web host set things up versus how PHPSec is recommending that I harden my php.ini file.

Is that correct?


Rob

You don't have any choice.

I do have a few choices.

1.) I could pay advanced support to do all the fancy stuff you mentioned above, and make it so Apache recorgnizes my folder called "tmp_uploads". (And I could start fasting to pay for it.)

2.) I could request Root, and dare to trigger the Apocalypse!

3.) I could hope that whatever IMH chose as defaults will work for my upload script. (Not a good idea if you ask me!)


Another challenge to tackle...

Gee, all of this web-hosting stuff is really dragging down the fun of finally getting ready to "go live"! *sigh*


Rob

Why not define it to a plae you do control? Like your home directory?
So if your web server is going to be located at ~/webserver/root_of_dir/ place it in ~/webserver/upload_tmp/

As for the second, limit the directory permissions to be 700. This means only you (the owner) can access the directory.
Obviously, root can access any directory whenever though.

Even a single user computer has many users. For example, the apache webserver runs as www-data (or nobody maybe) with very limited permissions to limit potentially damage if apache is hacked. It's a method of damage control.

If the place to serve web pages is indeed on /var/www and you don't have access.. well you're pretty much screwed. That's something to talk to your VPS about.

Could always go with a new server for web hosting that's more friendly.
I like nearlyfreespeech - but it's not designed to be friendly.
There's also many others that make it very easy (albeit more expensive)

Just something to consider before spending more money.

Yea, there are a lot of things that must be considered beyond the HTML when deploying a web site. It is only not fun if you don't understand much of the why and how. But you are learning, even if it is the hard way!

As to the php temporary file location - that is mostly important if you are on a shared hosting platform where there are other users not known to you. Uploaded files that spend time in the system /tmp directory may be accessible to them.

It is probably less important on a VPS where you are the only user - there should be no one else there to see them, and if there is someone else there, temporary file location is the least of your problems!

But still (excluding RedHat-isms mentioned by jpollard), /home/rob123/temporary_uploads should be a safe enough location with proper permissions. Assuming that your web server runs as the apache user and group, this should work:

If your webserver does not run as apache, set the group to the same group as files in your website tree.

"Outside your document root" basically means a location that cannot be hit by a browser. Assuming your document root to be /home/rob123/www or something like that, anything NOT under the .../www/ directory will do. The reason is that a common attack vector is for a badguy to upload a malicious php script and hit the upload location with their browser to gain access to your site. By putting the temporary location outside the document root - they can't hit it. This ALSO presumes that you check it before moving it to a permanent location too... more to do!

"Not readable or writeable by any other system users"... well, if you are the only system user on your VPS that base is adequately covered by /tmp. If you are on a shared host it is not.

Just curious, who is your VPS provider and what does their plan provide if root access is extra cost? To my own mind, VPS implies root access.

And root access is not apocalyptic - just requires knowledge and care - not a place to just try things!

1 members found this post helpful.

Because that violates the desired security recommended by the package.
In which case, the web server also cannot access the directory.

Well, first of all, my website is more than "HTML" - trying over 50,000 lines of hand-written code...

But, yes, I underestimated how much there is to web hosting and systems administration! (Nonetheless, I genuinely eager to learn as much as possible and someday become gurus like you guys!)


Okay, that is a good point. (I'm just trying to follow php.ini hardening advice I have found online to be doubly secure.)


Okay.


Here is what my php.ini files says...
I guess I need to find out what the default location is.

As long as it is outside of the Web Root, it sounds like wherever it is will be okay in my situation.

Then again, I would hope that it doesn't take much to include the new directory above in CentOS 6's "security directives" or whatever they are called?!


I think we are just using different terms for the same thing. I've always heard it called the "Web Root" - to emphasize things that can interact with the Internet.

Sounds like you guys use the term "Document Root".



My upload script is about 1,500 lines of code and does over a dozen checks to make sure an uploaded picture is indeed a picture. Of course, placing it outside the Web Root only makes things even more secure.


Okay.


BTW, some people have mentioned that another reason to create a temporary folder is to avoid collisions. Do I need to be concerned about that?

I assume that PHP is smart enough to make sure that things like Sessions and Temporary Upload Files are unique.


InMotion Hosting.


On my VPS, root access is free, but not included out of the box.

Thusfar, I have chosen not to have them turn it on, because I don't feel competent enough.

At the same time, I am starting to see that there are lots of things I need to do - or at least research - that I cannot without VPS root access.

This weekend will be very telling for me...

I hope to upload all of my code to my VPS - database code was already installed last week.

If my website runs okay in UAT, then I will leave things as they are for the time being. (I think the only thing left that I need VPS root access for is this temp folder issue.)

Assuming my website works okay after "go live", then maybe a few months down the road I will come up with an attack plan, and request Root access. But for now, as long as my website runs - and is secure - it is not my priority to play all day with Linux. (Nothing personal.)

I have always been of the mindset that if you understand how things work, you can be a better owner and operator. So I am totally into learning all about Linux and web hosting and so on!!

At the same time, my #1 priority is having a website that makes $$$. And assuming I have reasonable server security, I think my time is best spent on how my website looks and feels and CONTENT!!

One thing I have noticed about IMH is they seem to really caution me on acquiring Root access, "because you might break something we can't fix!!"

I sort of wonder if that is in reality a little self-serving, and their larger goal is just to keep me dependent on paid advanced support.


This is what I am thinking...

Assuming my $$$ situation improves, in a few months I will get a second, identical VPS with this current web host. And on this second account, I will ask for VPS Root access up front - this will be my "test box".

That way I am learning on the same environment as my live VPS, and if I break anything, nothing lost.

I think an extra $40/month would be money well spent! And hopefully after playing around with things for a few months, I would be ready to implement any and all Root changes on my production VPS.

Time will tell...

Sincerely,


Rob

It is usually easier to setup a VM of your own and do the testing there.

Your only need then is to replicate the environment provided by InMotion Hosting.

The advantage of your own is that you don't have to depend on them if something you are testing goes south and kills the system.