Which is best: Suphp vs. mod_ruid2

J

jim.thornton

Verified User
Joined
Jan 1, 2008
Messages
334
I've currently got a VPS setup at a provider and the setup is using PHP in FastCGI mode w/ suphp. There are not a lot of user's websites on the server at this time, but they are pretty much all using Joomla. All the files are 644 and the directories are 755. As you know higher privileges than that will fail with a 500 server error.

I'm now installing DA on a new VPS (with a different provider) and this time I am configuring everything myself. What I would like to know is, should I use the same setup I have or should I switch to mod_ruid2.

I'm not familiar with the differences except my understanding is that suphp added security because it required the files to be owned by the user in order to display them. My understandin is that by doing this, they could not run a file in a different location (i.e. /tmp).

I have secured /tmp, /var/tmp with noexec,nosuid,nodev and I have secured /home with nosuid.

Could someone please advise me on this setup. I currently don't have a lot of users in the shared hosting environment, infact, I have none other than accounts that I manage. But, I would like the system setup to be secure so that I can sell shared hosting accounts.
 
@ jim: How do you secure /tmp, /var/tmp with noexec,nosuid,nodev and I have secured /home with nosuid?

What commands do you use? is there any guide for that. I am not expert in linux, but I know basic commands to use it.

jim.thornton said:
I've currently got a VPS setup at a provider and the setup is using PHP in FastCGI mode w/ suphp. There are not a lot of user's websites on the server at this time, but they are pretty much all using Joomla. All the files are 644 and the directories are 755. As you know higher privileges than that will fail with a 500 server error.

I'm now installing DA on a new VPS (with a different provider) and this time I am configuring everything myself. What I would like to know is, should I use the same setup I have or should I switch to mod_ruid2.

I'm not familiar with the differences except my understanding is that suphp added security because it required the files to be owned by the user in order to display them. My understandin is that by doing this, they could not run a file in a different location (i.e. /tmp).

I have secured /tmp, /var/tmp with noexec,nosuid,nodev and I have secured /home with nosuid.

Could someone please advise me on this setup. I currently don't have a lot of users in the shared hosting environment, infact, I have none other than accounts that I manage. But, I would like the system setup to be secure so that I can sell shared hosting accounts.
Click to expand...
 
SolidState said:
@ jim: How do you secure /tmp, /var/tmp with noexec,nosuid,nodev and I have secured /home with nosuid?

What commands do you use? is there any guide for that. I am not expert in linux, but I know basic commands to use it.
Click to expand...

Here you go. This should get you going:

http://www.cyberciti.biz/faq/linux-add-nodev-nosuid-noexec-options-to-temporary-storage-partitions/

However, when I first got a VPS I tried to do it and kept getting errors. I'm pretty sure that you can only do it if /tmp is a separate partition. Same with /var and /home. My first VPS was OpenVZ. I don't know if it was because of OpenVZ or not, but I had no access to my own partitions on that VPS. This time I have KVM which uses SolusVM. With this control panel, I was able to mount a CentOS 6 install DVD and install the OS with a disk that was divided into different partitions.

Someone else can chime in here if I'm wrong as I'm no expert either, but it's what worked for me.
 
I'm pretty sure that you can only do it if /tmp is a separate partition.
Click to expand...
Nope. It depends on the VPS node settings or the Vps system used, I'm not sure there. We've got one vps on which it works and one where it was not possible.
On dedicated servers it always works, no /tmp partition needed.

In another thread I put the commands togetherin one post, which works without a tmp partition and which works better the the link you pointed to.
 
Richard G said:
In another thread I put the commands togetherin one post, which works without a tmp partition and which works better the the link you pointed to.
Click to expand...

Two things:
1. Can you share the link for the other user? Just saying "another thread" doesn't help them. I'm sure they did some searching but didn't find what they needed.
2. How can it work "better"? If the link I provided works.
 
1. Sometimes it helps search other ways like with Google (secure /tmp+directadmin) or here on the forum with "nosuid" as search string I found it instantly or search for my username and secure in combination?
But oke here is the link, I had too look for myself the same way you have to do but was too tired yesterday to have a look:
http://forum.directadmin.com/showthread.php?t=49200
2. If something works, it does not mean there is no room for improvement or it can't be done better. The "better" part is that the commands to backup /tmp content before changing is present amongst other things like the importand chmod 1777 /tmp. ;)

However... securing /tmp either ways does not work on every VPS system. On my servers I also secure /dev/shm but I'm not sure if that is still necessary these days.
 
Last edited:
For who's interested, I use this to secure /dev/shm.

In /etc/fstab change:
Code: 
tmpfs /dev/shm tmpfs defaults,rw 0 0
to
Code: 
tmpfs /dev/shm tmpfs defaults,nosuid,noexec,rw 0 0
Then remount:
Code: 
mount -o remount /dev/shm
ready.

Securing /tmp and /dev/shm as described by me is for Fedora/Centos kind systems. I don't know if these exact commands also work on Debian etc..
 
Should I change my method and do what you did, or is the end result the same??

Also, you mention chmod'ing /tmp to 1777 is important. How so? What exactly does that do?
 
If your /tmp already exists and is on your root filesystem, you can still secure it following the directions you see on http://www.cyberciti.biz/faq/howto-mount-tmp-as-separate-filesystem-with-noexec-nosuid-nodev/. Basically you are creating a filesystem in a file that will be mounted with more secure options than your root filesystem. If you do this method, you may even want to temporarily mount the filesystem on /mnt and then move all the files from /tmp/ to the newly mounted filesystem so that when you finally mount it on /tmp any needed files will be there.
 
Should I change my method and do what you did, or is the end result the same??
Click to expand...
The choice is yours ofcourse, but I would suggest to change to what I did.
The result is very similar, but not completely the same. There are 2 important and one maybe less important differences.

1.) My method has the 1777 chmod, it's on the other url now too. Maybe I missed it he first time I looked at the url or they corrected it afterwards.
2.) My method also fixes a possible problem with logrotate.
3.) I would never want to have something user accesible in my /root folder (just to be sure), that's why I created the /temp in the /var folder. Maybe I'm a bit paranoid with this, but I just don't like "non-root" stuff in the /root folder.

But again... it's your choice, you can use either method, the end result just has some slight (imho important) differences as you can see.
 
Richard G said:
1.) My method has the 1777 chmod, it's on the other url now too. Maybe I missed it he first time I looked at the url or they corrected it afterwards.
Click to expand...
I just looked at my privileges on /tmp and they are also 1777.
2.) My method also fixes a possible problem with logrotate.
Click to expand...
What problem with logrotate. My files have been rotating file (at least I think they have).
3.) I would never want to have something user accesible in my /root folder (just to be sure), that's why I created the /temp in the /var folder. Maybe I'm a bit paranoid with this, but I just don't like "non-root" stuff in the /root folder.
Click to expand...
The link I had set the /var/tmp to go to the /tmp folder anyway. I guess you could just do it the other way around anyway. However, does it really matter if the /tmp folder is in the / directory? If users don't have privileges for / anyway, what is the difference?

But again... it's your choice, you can use either method, the end result just has some slight (imho important) differences as you can see.[/QUOTE]
 
1.) Great... if your's is on 1777 you're ok.

What problem with logrotate. My files have been rotating file (at least I think they have).
Click to expand...
2.) You shouldn't think in this business... you should be sure. :D
Logrotate is using /tmp to execute scripts before and after log file rotations. Some of those are used to restart/refresh a daemon so it can start logging to the newly created logfile. How do you expect scripts to be executed on something which is declared as noexec?

3.)
However, does it really matter if the /tmp folder is in the / directory? If users don't have privileges for / anyway, what is the difference?
Click to expand...
No that does not matter.
But I'm sorry... the link you set did indeed not point to /root but to the / directory. It was the link set by Toml which pointed to /root for the /tmp.
 
Thanks for the clarification about logrotate, Richard.

I'm Running CentOS and I've noticed on some of my servers I've had /tmp set up with noexed. I've just removed it on one of my servers for testing purposes; now I've got:
Code: 
defaults,nosuid,nodev
Do you believe this to be good?

Jeff
 
Richard G said:
Logrotate is using /tmp to execute scripts before and after log file rotations. Some of those are used to restart/refresh a daemon so it can start logging to the newly created logfile. How do you expect scripts to be executed on something which is declared as noexec?
Click to expand...

I've never faced such an issue. How much is that actual for a standart set of software (LAMP) on Directadmin powered server? Do you know which exact services do require it?

What I know for sure, that debian and ubuntu when upgrading with apt-get and aptitude execute some scripts in /tmp. And here you could either re-mount /tmp with exec option to do upgrades or ignore it at all.
 
Alex,

Thiough your reply wasn't meant for me it pushed me into looking at log files. The only anomaly I've found so far is that the older machine has no files named /var/log/dovecot*. The newer machine has these, all empty:
Code: 
-rw-rw----. 1 mail mail 0 Dec 13  2013 dovecot-debug.log
-rw-rw----. 1 mail mail 0 Dec 13  2013 dovecot-lmtp-errors.log
-rw-rw----. 1 mail mail 0 Dec 13  2013 dovecot-lmtp.log
-rw-rw----. 1 mail mail 0 Dec 13  2013 dovecot-sieve-errors.log
-rw-rw----. 1 mail mail 0 Dec 13  2013 dovecot-sieve.log
It appears these files were built when the server was, and never udpated.

I suppose dovecot may log elsewhere on both servers, and I don't see this as a problem.

That said, I don't want one in the future.

Juggling now with the increased security (is there any, or is only perceived?) vs the assurance that logs will get properly rotated for any changes in the future.

At this point I'm still okay with leaving noexec in, but I'm open to further discussion.

Jeff
 
The following needs to be set in dovecot.conf to write to lmtp log files:
Code: 
service lmtp { 
executable = lmtp -L 
}

I think John is planning some changes for dovecot/exim (together with the SpamBlocker 4.2.2), so you may ask him about this change also (if there are plans to use the separate log files). At the moment everything from dovecot is logged into /var/log/maillog.
 
Thanks, Martynas. John and I are in touch on a regular basis on going forward with SpamBlocker exim.conf files, and I'm aware of most issues and some plans.

However I'm also concerned about anything else in the future which may require exec priviliges in /tmp. I suppose I should read RedHat developer's documentation, or ask on redhat-usrs list.

Jeff
 
You must log in or register to reply here.
Back
Top