Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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
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.
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.
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:
- new tmp partition is formatted and ready to go [called /dev/hdb5 in example],
- you are in runlevel 3 (runlevel 1 is better).
- 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)
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.
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.
- 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.
Last edited by stress_junkie; 09-13-2006 at 11:39 AM.
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.