Would Admins like to see cPanel develop a chrooted system for each account?

  • Yes!

    Votes: 323 91.2%
  • No!

    Votes: 9 2.5%
  • What's chroot?

    Votes: 22 6.2%

  • Total voters
    354

rs-freddo

Well-Known Member
May 13, 2003
834
1
168
Australia
cPanel Access Level
Root Administrator
At some stage I need to move to RHEL. This will mean downtime while I move accounts. At this stage I'm seriously thinking that it would be better to just get an Ensim Pro server and move people off cPanel altogether - no downtime and less chance of more downtime through getting hacked. Ensim Pro on RHEL is looking pretty good to me.
 

rs-freddo

Well-Known Member
May 13, 2003
834
1
168
Australia
cPanel Access Level
Root Administrator
Originally posted by cyon
we all know, that the developers browse this forum at least once a week.
it's impossible to miss that thread, so why is it such difficult to give a little feedback?
a "we have no plans yet" is still better than nothing, isn't it?
Unfortunately silence says a great deal. In this case it says - "no way - ever!".

cPanel is too busy doing Fantastico look alikes called cPanel Pro. There is nothing in cPanel Pro that couldn't be done using Fantastico. cPanels inability to service it's own renditions of phpBB prove that it will not be able to keep cPanel Pro up to date - and to charge extra for the privelege!.

My personal opinion is that the cPanel developers have lost the plot. Certainly people want the bugs fixed before new features. But to see dumb new features like Pro being implemented, when real security is ignored - that just doesn't bode well for cpanels future.

IMHO the developers need a swift kick up the ass.
 

ameen

Member
Apr 27, 2002
19
0
301
The vserver project is for virtual servers (vps, vds) i do not see how using vserver pertains to cpanel chrooting more stuff.

They already have vserver functionality too.
http://layer1.cpanel.net/cpanel-vserver-install

Secondly, ensim is not 100% chrooted, ssh LOGINS are chrooted, not the SSH daemon itself, and so is cpanel's ssh. PROFTPD in both ensim and cpanel chroots ftp sessions but proftpd does not run chrooted.

Ensim chroots's CGI scripts but what difference does it make when you can execute a php script and see everything below /home/virtual/.

APACHE, PROFTPD, SSHD are still ALL suspceptible to exploits, and when exploited it wont make a DAMN difference in the world if the user is chrooted when he is logged in, the program doesnt run chrooted, it chroots the user at LOGIN/sessions.

chrooting an ssh, ftp or cgi session is only good to prevent users from snooping around. Again, it will not stop a person from exploting a bug in apache, sshd, ftpd and gaining privelaged access.

The only program which can run under a TRUE chrooted environment in any of these systems is named, and i dont think either cpanel or ensim run named by default chrooted.


Chrooting is not going to secure your machine and keep hackers out, keeping it up to date with patches and doing generaly security tweaks will.


If you want a secure environment the best protection is grsecurity with ACL's. But then alot of stuff will break.
 
Last edited:

rs-freddo

Well-Known Member
May 13, 2003
834
1
168
Australia
cPanel Access Level
Root Administrator
Ameen

I have used Ensim Pro and was pretty unimpressed with the chrooted system HOWEVER results speak for themselves. In the last couple of months LOTS of cpanel servers have been compromised whereas none/very few Ensim pro servers have been compromised. Lets forget outdated kernals and apache etc - I agree with you, if they are not kept up-to-date the CP doesn't matter. What i am talking about is getting compromised from the user account. A lot more people are using GPL scripts and a lot of them are rubbish - totally insecure.

With the Ensim chroot, if someone breaks into the account, there is nothing much they can do. They cannot run a lot of the server software from SSH or scripts. If they use scripts (perl or PHP) to attack another server, you do not need to restore the whole server - JUST THAT ACCOUNT. I guess this is the most important part for me. In Cpanel once someone is into /tmp - that's it, your looking at pretty much a server restore.

I would love to be wrong on this issue - but so far you are the only one who has defended the cpanel stance, certainly cpanel hasn't bothered to.
 

pagedeveloping

Well-Known Member
Jun 11, 2003
219
0
166
New York
Originally posted by ameen
The vserver project is for virtual servers (vps, vds) i do not see how using vserver pertains to cpanel chrooting more stuff.

They already have vserver functionality too.
http://layer1.cpanel.net/cpanel-vserver-install

Secondly, ensim is not 100% chrooted, ssh LOGINS are chrooted, not the SSH daemon itself, and so is cpanel's ssh. PROFTPD in both ensim and cpanel chroots ftp sessions but proftpd does not run chrooted.

Ensim chroots's CGI scripts but what difference does it make when you can execute a php script and see everything below /home/virtual/.

APACHE, PROFTPD, SSHD are still ALL suspceptible to exploits, and when exploited it wont make a DAMN difference in the world if the user is chrooted when he is logged in, the program doesnt run chrooted, it chroots the user at LOGIN/sessions.

chrooting an ssh, ftp or cgi session is only good to prevent users from snooping around. Again, it will not stop a person from exploting a bug in apache, sshd, ftpd and gaining privelaged access.

The only program which can run under a TRUE chrooted environment in any of these systems is named, and i dont think either cpanel or ensim run named by default chrooted.


Chrooting is not going to secure your machine and keep hackers out, keeping it up to date with patches and doing generaly security tweaks will.


If you want a secure environment the best protection is grsecurity with ACL's. But then alot of stuff will break.
Like I said it before and I will say it again,

Perhaps cPanel already knows and they are just toying with us, huh!
 

cyon

Well-Known Member
PartnerNOC
Jan 15, 2003
320
0
241
Originally posted by pagedeveloping
Perhaps cPanel already knows and they are just toying with us, huh!
I don't see any reason why the developers should toy with their customers.. :confused:
 

pagedeveloping

Well-Known Member
Jun 11, 2003
219
0
166
New York
Originally posted by cyon
I don't see any reason why the developers should toy with their customers.. :confused:
cyon, the post by ameen points out facts that cpanel already knows all about chrooting.

My post is just a kidding sence of humour around the issue.

I don't think cpanel would toy with us, or would they?

Just kidding cyon! :D
 

rs-freddo

Well-Known Member
May 13, 2003
834
1
168
Australia
cPanel Access Level
Root Administrator
Originally posted by pagedeveloping
cyon, the post by ameen points out facts that cpanel already knows all about chrooting.
AFAIK ameen is not associated with cPanel. He is just a cPanel user, like me and you.
 

damainman

Well-Known Member
Nov 13, 2003
515
0
166
I smell a protest beggining lol

I was hopeing they would address if not major, atleast minor security issues before the next STable release of Cpanel.

I keep seeing pre-stable releases, although they do seem to be fixing some bugs, i've yet to see any updates pertaining to secruity.

I rather have a secure system with no features, then a feature riched system that gets hacked daily because of lack of secruity.
 

pagedeveloping

Well-Known Member
Jun 11, 2003
219
0
166
New York
Ok rs-freddo,

I had to read your post another time and I have to say, where is it cpanel fault if some one breaks through your /temp?

In Cpanel once someone is into /tmp
You don't need cpanel to have your /tmp broke into. In fact if you are having those kinds of problems than you need to /tmpMnt "you know the deal"

Last server I recall was hacked through ftpd which pureftpd claims "Nothing can get through our ftp" and this server had no cpanel in sight.

Since I have been using cpanel everything has been tight except for that damn demo which was compromised through once again pureftpd.

so don't be leading these people with false information that a chroot will pretect their /tmp and that it is cpanels fault if it gets compromised.

And, If your so concern about this issue than why are you using cpanel at all?

cpanel knows about chroot and if they new it would protect you from harm than I bet a million they would have gone that route.
 

SarcNBit

Well-Known Member
Oct 14, 2003
1,010
3
168
The only two comments I have seen made against the incorporation of a proper chroot environment (and I have no idea how the two posters ultimately voted) seem to suggest that;

A. cPanel needs to concentrate on fixing what they have before installing new features

B. chroot isn't the end all solutions for securing your server

I agree with both points. Neither of the objections (???) given however really support no votes. With regards to point A, I believe that making the product more secure is part and parcel to fixing what they have. With regards to point B, I think that most of the contributors to this thread agree that no one solution will give us 100% security. I still support the notion of "taking it where I can get it" when it comes to security. I would welcome a proper chroot implementation and I would prioritize it above the addition of new packaging features.

I have to wonder if some of the "non-yes" votes were simply the votes of that strange group of people that like to vote against whatever seems popular.
 

cPanelNick

Administrator
Staff member
Mar 9, 2015
3,488
35
208
cPanel Access Level
DataCenter Provider
A proper chroot system requires a complete copy of all the system libs in a virtual dir.

To make sure every perl and php script runs, you'll need to make sure you have a copy of the perl and php modules installed as well.

If you want apache to run inside the root for each user, you'll have to give up pre-forking, and take a large performace hit.

If you want a true chroot system, expect about 1.5 gigs extra for account and about 1/2 the http performance.

Linux chroot() isn't secure anyways. Once you obtain root in the chroot you can easily get out anyways.
 

anand

Well-Known Member
Nov 11, 2002
1,435
1
168
India
cPanel Access Level
DataCenter Provider
Originally posted by bdraco
A proper chroot system requires a complete copy of all the system libs in a virtual dir.

To make sure every perl and php script runs, you'll need to make sure you have a copy of the perl and php modules installed as well.

If you want apache to run inside the root for each user, you'll have to give up pre-forking, and take a large performace hit.

If you want a true chroot system, expect about 1.5 gigs extra for account and about 1/2 the http performance.

Linux chroot() isn't secure anyways. Once you obtain root in the chroot you can easily get out anyways.
Its good to know Nick. Thx for the info.
 

X-Istencedotcom

Well-Known Member
Apr 14, 2003
223
0
166
I move away from ensim, cause chrooted envoriment and whatnot is starting to bog down server resources, and whatnot, and then cPanel wants to move towards it?, I am all for it, just make sure it does not heavily affect server resources.
 

perlchild

Well-Known Member
Sep 1, 2002
279
0
166
Originally posted by Dreamer
I see no reason to vote with answer other than 'yes'. It is, however, quite strange that after this problem is nothing new and the are too many complaints from the users nothing is being done to change this. Or it look like...
Probably some people's idea of "properly" is "too restrictive for xyz use of the server...
Say they developed a solution somewhere, that would need be rewritten in a chroot environment?
 

perlchild

Well-Known Member
Sep 1, 2002
279
0
166
Originally posted by bdraco
A proper chroot system requires a complete copy of all the system libs in a virtual dir.

To make sure every perl and php script runs, you'll need to make sure you have a copy of the perl and php modules installed as well.

If you want apache to run inside the root for each user, you'll have to give up pre-forking, and take a large performace hit.

If you want a true chroot system, expect about 1.5 gigs extra for account and about 1/2 the http performance.

Linux chroot() isn't secure anyways. Once you obtain root in the chroot you can easily get out anyways.
I think you still have featuritis here...
certainly, if you want a secured, chrooted version of the cpsrvd daemon, you don't want it to have the capability to load ANY dynamic modules of any kind, and want it to run linked statically...
That means whatever php runs in cpservd would need to be also built statically if at all possible, or else you need to remove php from themes, etc...

Having a seperate copy of the OS in a sort of virtual filesystem would NOT make the system more secure, since we would need to secure BOTH copies...
Having a deliberately limited feature set, with statically linked, audited binaries is however, something that might provide extra security in the context of something like cpservd. A small, limited context. You would need to move the config files out of /etc in some cases though...

Actually I voted "yes" and I just realized I should have voted "yes" mostly because the password file is not in the chroot, and can't safely be placed there... (ok sshd can use a pam module that allows the ssh service to use a password file located elsewhere, but that's not the current state of affairs)

Basically the one problem I see(although I still support the idea of securing cpsrvd a lot), is that it needs to write to a lot of files that should never be accessible from inside a "restricted" chroot...

(You don't want the chroot just to prevent reseller 1 from seeing reseller2's files, you want the chroot so that if cpsrvd is ever hacked, no extra access to the system is gained)

One way to do this would mean a pair of daemons, one that runs as cpsrvd inside the chroot, passing commands to one outside, that performs the changes to the file, after validation for policy etc...
 

Zamolxe

Registered
Feb 9, 2004
1
0
151
chroot

yes, i totally agree with a chrooted environment. but this will only increase the security on the web/customers side.

during these days i have ran some security tests on cpanel, and these are the problems that ocurred:

1. if the admin creates a demo account the system can be compromised via php. accesing the ftp with the default login you can place an evil php script and browse through system.
2. if a customers registers, he can compromise the system too, even if the functions exec, popen, etc. are forbidden. its all done because of the functions dir, fopen, show_source, etc.

Of course there are some minor methods with which you can prevent this, but the user still can get out of his box and 'see' private stuff like /etc/passwd

Here is what i recomand to all cpanel users:

1. When create a demo account, CHMOD -R 000 /home/demo, so if the user connects via ftp cannot manipulate the files
2. in php.ini do the following:

disable_functions = exec, passthru, shell_exec, system, popen, virtual, show_source, readfile, pclose

I am shure that the functions above will not affect you customers scripts. Thou if you restrict fopen or other file manipulating function, it will affect other possible non-harmful clients scripts.

NOTE: if you activate safe_mode, or open_basedir, you will have a lot of problems with the customers scripts.

3. disable anonymous acces
4. disable shell acces (i am shure that on a webhosting server this option is not necessarly needed)
5. disable cronjobs

hope this helps.

ps: i have tested and 'compromised' over 10 server till now with the bugs described above.