Greetings.

I'm trying to secure the /tmp directory on a single partition CentOS 3.8 installation. The following 'standard' approaches to implementing noexec on /tmp aren't working, for the cited reasons...

1) Initially mounting /tmp as noexec isn't possible, as the entire OS installation is on a single partition (VPS environment)
2) Creating a file-based filesystem device and mounting using -o loop isn't feasible, since the VPS environment I'm using doesn't support the loop device.
3) Using mount --bind isn't working. I've read that when you're using --bind, other options are ignored by mount. The solution to this is to immediately following the mount --bind with a mount -o remount, which will properly engage other options such as noexec. However, the remount is failing with a "mount: permission denied".

Can anyone out there please provide some guidance on how to secure /tmp on a single partition environment, either with an option I haven't listed or some insight into the permission problem affecting #3.

Centos 3.8 under FreeVPS 2.4.21-freevps-1.5-7smp. Mount version is 2.11y

Thanks.

- Mike

I curious as to why you want to 'secure /tmp'?

As a rule of thumb /tmp is normally open. The OS and many pgms / scripts use tmp for temporary storage while they are operating.

if suppose a hacker get access to your system using some kind of php shell injection, he would have the priveleges of apache,www,etc. in that case he wont be able to execute stuff on your system if you have noexec /tmp. anyhow, but you would need to make sure that there arent any "777" folders on your comp.

zman818,
you could try creating a new partition for /tmp, edit the fstab file and all. I am not sure whether its the best way to do it.

Hi,

I'm not sure what you mean by secure. It could be placing /tmp on it's own partition (steps to do that are at the bottom). It could also be that you want to stop user from executing files in /tmp.

The last part is not a good idea. /tmp is used and needed by many programs.

And that is stated by FHS (although that's not official yet): The /tmp directory must be made available for programs that require temporary files.

Here's an easy way to get /tmp on it's own partition:

Assumed:
- new tmp partition is formatted and ready to go [called /dev/hdb5 in example],
- you are in runlevel 3 (runlevel 1 is better).

Steps:
- add line to fstab: /dev/hdb5 /tmp ext2 defaults 0 2,
- throw all users off your box (1 user, root should be present. Not needed when in runlevel 1) ,
- empty present /tmp rm -rf /tmp/* (I don't know if CentOS does this during the going down face of the reboot, it's to be sure),
- reboot init 6.

When the system comes up again your /tmp should be on /dev/hdb5 (df -h to check).

- Do check the permissions on /tmp. It should be: drwxrwxrwt (chmod 17777 /tmp to set permissions)

Hope this helps.

Thanks, but as mentioned, the entire deployment is a single partition. Creating a new partition to house /tmp would be an easy solution, but it's not an option.

Best practices for web servers strongly suggests that /tmp be secured with noexec, among other options. SQL and code injections oftentimes rely on the ability to upload a trojan to the /tmp directory. If /tmp is on its own partition (or simulated partition through a loop device or --bind) and the partition does not support execution, it essentially thwarts the hack.

Though certainly possible, it's not common for applications (IMHO, anyway) to rely on execute priviledges for temporary files in the /tmp directory. The /tmp directory is certainly write-available, just not execute-available. Sorry if my original message was ambiguous.

zman 818,
I absolutely agree with you regarding the /tmp directory. Your configuration looks as if you have eliminated your options to achieve your goals. It seems that your best choice at this point is to add a disk drive that can hold your /tmp directory. Then you put a partition on there and mount it -noexec.

Also, you mentioned web server configuration. I don't know if your machine is a web server. You should know that web server daemons should be chrooted into some directory that will hold a tmp directory within that jail. So if you chrooted a web server daemon into /chroot/webchroot you would have /chroot/web/chroot/etc, /chroot/webchroot/home, /chroot/webchroot/tmp, and whatever else is required in the chroot environment. In that case you would want to secure the /chroot/webchroot/tmp directory against executing files. I hope I haven't been too obtuse.

In summary:
- Add a disk to the computer to hold a partition for /tmp.
- Chroot your web and other service daemons.
- Secure the tmp directory in any chroot jail. You may need to have a partition on your added disk for this purpose.

Otherwise I think you have painted yourself into a corner with the current configuration.

Thanks SJ. Yeah, I'm definitely scraping the bottom in terms of options. The --bind / remount option looked promising, but until I can understand why mount -o remount yields a permission denied issue (it shouldn't, but it does), I guess I'm SOL.

I understand completely regarding chrooting the web server. In fact, my goal is to go one further and create a private /tmp for each site (I've already implemented suexec and suphp, though I'm waffling on suphp due to performance issues).

Of course, chrooting apache means breaking a lot of things currently in place, but if I'm going to wave the Best Practices flag, I need to deal with that stuff humbly and quietly.

Thanks for the responses.

Regards,
Mike

How about making /tmp a tmpfs?