Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Ive been trying to lock some security vulnerabilities at my server, and I got to the point of the tmp folders. Both of them will store files that are used by other resources, still, reading a little more I found out that the /tmp could save some data that involves the server itself instead of the /var/tmp.

My question is, What are the implications of securing write access to /tmp and /var/tmp. I already tried securing /var/tmp and until now nothing bad has happened.

Is it safe to block /tmp and deny saving files that could damage my server or could there be a type of spam or something similar that affects my security? What is the vulnerability if I allow access on my server to these folders, say writeable with 777 permissions (like they come by default)

Thanks

share|improve this question
1  
Leaving those directories as they are (including s bit) should not cause any security vulnerabilities. Making them read only is likely to break many programs. (e.g. vi(m) which saves its recovery information in /var/tmp and expects it to be present, even after a reboot.) (Note: /tmp may be wiped on a reboot, /var/tmp should not be wiped.) –  Hennes Sep 13 '12 at 23:10
    
Thanks, the problem is that I am hosting some applications and some of them have security problems (I can not fix them for internal decitions) and I want to be secure nobody will reach my tmp folders, or other folders...I read someone could upload files to my /var/tmp directly from an application. –  jpganz18 Sep 13 '12 at 23:14
1  
Then you have a problem. You might not have noticed anything breaking yet, but /tmp and /var/tmp are supposed to be writable. If you change that you will need to check each and every program on your server. Both which are installed now and those you will install in the future. That is a heck a lot of work. :-( –  Hennes Sep 13 '12 at 23:18
    
If you are running poorly written programs, then I suggest you look at using a chroot, VM, or some other sandbox type setup to separate the buggy programs from the rest of the system. –  Zoredache Sep 13 '12 at 23:25
    
thank you for your replies, which sandbox could I use for a linux server? which is the best according your experience? –  jpganz18 Sep 13 '12 at 23:40

2 Answers 2

up vote 6 down vote accepted

/tmp and /var/tmp are supposed to be world-writable so that all programs/users can create their temporary files there. The sticky bit ensures that only the owner (and root of course) can move/rename/delete the file (see chmod(1)). Of course an application could still set insecure permissions on files, allowing read- or write-access to the wrong user(s), but that's up to the application and has nothing to do with the permissions on those directories.

share|improve this answer

/tmp and /var/tmp were historically well-known locations where programs could store temporary files. However, to function properly they have to be world writable (and sticky). This works, but it also opens up a wide variety of potential security issues with one program writing temporary files that another program will read, thus causing the second program to behave in unexpected and undesirable ways.

The first "fix" for this was to have all programs writing temporary files to use a system call to generate random filenames. This sort of works, but it's dependent on (1) the program actually using it; (2) having a secure RNG; and (3) luck.

There's a move on in the Fedora Project to have system services each use an independent private temporary directory accessible only to that service. Each program sees and uses /tmp but they are actually namespaced bind mounts managed by the system. Very clever solution, and one I suspect will start showing up in other Linux distributions soon.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.