Despite my overall disliking for cPanel/WHM, one feature that it has that comes in very handy is the Jailshell. Hosting clients, when granted shell access, should not be able to see anything except for their domain, their files, and their folders. They should feel like they are the only ones on the system.

I believe that jailshell also keeps people from even attempting anything malicious or overstepping their bounds, simply because they can't even try to open files that they shouldn't, because they are invisible to them.

The Virtualmin vs. cPanel comparison as a selling point should not ignore the lack of this feature. Jailshell is an important tool for web hosts because of the growing number of customers who request shell access with no intention of harming the system or gaining access to other users' files.

Hi James,

Interesting, thanks for bringing this up! I really do want the comparison to be fair to cPanel, as I don't see any point in bringing someone over to Virtualmin only to have them disappointed by some lacking feature that we didn't mention in the comparison. I never noticed this feature in the cPanel documentation, but will look into it now. jailshell does sound like a very nice feature.

I'll update the cPanel comparison, and look into getting something similar into Virtualmin Professional. We do have some plans that go well beyond this, but in the short term it seems like a good idea.

Hey James and all,

I've done some research, and something along these lines is absolutely do-able. There are a few options out there and I thought I'd post them here and get some opinions if anyone has tried them:

JailKit: This one is the most mature and has a very competent developer behind it, but is also the most complicated. It sets up a chroot environment for shell users, and includes some tricky wrappers for things like procmail to prevent jail breakage via roundabout methods. It is quite complex in that in order to make the shell useful, we have to drop everything a user is going to use into the jail. This one would take a week or three to integrate into Virtualmin Professional. http://olivier.sessink.nl/jailkit/

ibsh: The Iron Bars Shell. This one is quite new, but looks like it has some great features. It is a very restrictive "deny everything unless told otherwise" shell, with much easier configuration than JailKit. It sounds like it does everything we'd like it to do, but I have concerns about its security due to its young age. There just isn't enough history to it for us to know if it is truly safe without a code audit (and even then something might get missed)--by the time we've audited it, we could have integrated JailKit, which has a track record. Without the audit, it could go into the very earliest beta versions this week. I really like the idea of this one, due to its simplicity...but it's pointless to choose something simple if it doesn't work. http://ibsh.sourceforge.net/

scponly: This one is the most restrictive of them all, and probably doesn't answer everyones needs in this space. On the other hand, it is extremely simple and easy to integrate into Virtualmin Professional, so it is going in whether we choose it as the primary "limited shell" option or not. It's just a good idea done well. Anyway, it wraps ssh to only permit a very limited subset of features--like scp, sftp, rsync, and CVS. Would this limited feature set be enough for your users that you don't trust with straight shell access, or do we need to pursue one of the more flexible options? http://www.sublimation.org/scponly/

rssh: Roughly the same as scponly. I've found fewer users talking about it, but it's probably just as good. Worth trying before choosing scponly for the specific problem they solve. http://www.pizzashack.org/rssh/

Thanks in advance for any thought anyone has on this one, or suggestions for other options that might solve the problem.

OK, I've added scponly to the installer and it will show up in the shells dropdown list when creating new templates. I'm working on building a chroot environment for it, so that scponly shell users won't be able to see the rest of the world...this same process should speed adoption of jailkit or something similar. I haven't figured out which of the full-featured, or I guess partiall-featured, restricted shells we'll be using--ibsh is really cool, but much less mature than I'd like...it doesn't even have tab completion or history!

I've updated the cPanel vs. Virtualmin Professional chart to include this feature (and I give us a yellow dot vs. their green, until we have a more complete solution in place).

I am very glad to see that such an immediate response was initiated to include this feature. I am continually more and more convinced that Virtualmin is the future of web hosting control panels. Thanks Joe!

Hello Joe,

I was wondering how the restricted shell access is coming along? I also would like to offer some assistance and a suggestion that would be nice for this feature. I have been stuck with virtualmin version 1.4 since the day of its release (I know, thats old). The reason is I completely revamped virtualmin to support restricted shells since then. Any upgrades would ruin my work. The following are current features I have:
1. When adding new customers it creates a restricted shell account under /home/(user-admin).
2. I give my customers the ability to add restricted shell accounts as well.
3. The restricted accounts they add are placed under /home/(user-admin)/homes/(admin)
4. So when my customer logs in they can see all their sub accounts, while those users only see their account.
5. I also limit the number of accounts my customers can add.

Since I add this its worked flawlessly and I have a lot of accounts based on the scheme.

I am writing this cause it would be nice to start using some of the new features virtualmin has. I am hoping you might see a future for these features in virtualmin. If you need any asistance feel free to ask.

Thanks

Hey Bryan,

As mentioned in the post above, scponly is now included in the default install and works really well for the things that it does. It is not the solution for all situations, however, so I'm still thinking on other ideas.

I'd certainly welcome feedback on how you're accomplishing your restricted shell environment. Are you using one of the tools I've mentioned previously, or a custom chroot-based solution?

Basically I am using a patch on SSH service. It looks at user's directory path. If they have a path like so:

/home/user/./files/

SSH restricts them from ./ on up when they login.

I have modified virtualmin and webmin to include /./ with every account creation. Also I have updates the /etc/skel dir to include files for all jailed accounts. That is it...besides the fact of adding limits for accounts.

Chroot/jail type behavior is quite an important concept to address. Is there a solution to this problem yet? I have scponly installed, and it works a restricted shell, but we would like the default situation to jail clients to their own home directory - without any command line intervention. If there is no virtualmin method, then how are other people dealing with this?

Hi Pasi,

If you have a very recent OS (one with Dovecot 1.0), you can lock down permissions very tightly, which resolves this issue entirely (without need of potentially very dangerous tactics like chrooting shells*).

We're rolling out Dovecot 1.0 to everyone over the next few days, which will allow us to make the default 750 for homes.

If you're running one of the operating systems that has 1.0 already (just FC6 and maybe Ubuntu 6.10), then you can browse to the Webmin System Users and Groups module, hit Module Config, and change the default permissions on new home directories to 0750 (and chmod 750 /home/*). If not, you'll have to wait a few days until we can get it packaged up for everyone and documentation posted for helping folks make the transition to the new version.

*-A general purpose chroot shell (i.e. one filled with lots of regular software and programming languages) introduces several potentially huge security issues, and really just shouldn't be done. Now that I've researched the issue more fully I can say with confidence that we will never offer a chroot shell, by default.