Jailshell .. Should not be left out of the cPanel Comparison

Blue Skies
21

So I believe this is the reason why a FTP and/or SSH user is able to find and see most of the files and directories server wide.

It’s hard for me to tell whether this would mean potential security risks, but it would be better for FTP and/or SSH users to be restricted to their respective accounts/domains only.

Besides that, I’m quite happy with Virtualmin so far. :slight_smile:

22

+1 for this.

I still consider Jailshell insecure, because you can escape the chrooting with advanced skills, any SSH access to a server should be considered not safe. You need to trust the user first.

But I agree 100% with this request. For trusted users, which really need shell access, the only option is a jailed shell, and there are many options available, lets hope Virtualmin adds this as a feature soon.

23

Joe could you please let me know what happened from this 2009 statement?

“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!”

  1. Can I see a user guide for scponly in Virtualmin?

  2. Do we have a chroot environment like cPanel?

I don’t like Virtualmin users browsing the system. Not from web interface and terminal. It is no problem for webmin users.

24

chroot still only provides a false sense of security (I talked about this in a few other threads way back when this was a popular question, and we pretty much ruled out doing it in VIrtualmin because of the historic negative security implications, but even now, there is no security benefit to using chroot in this way).

scponly is no longer necessary, as ProFTPd supports FTP over SSH connections (though not general purpose ssh shell connections, but there’s no safe way to restrict a full shell user from seeing the rest of the file system). Using the DefaultRoot option, you can restrict any type of connection or any type of user to their home directory.

So to specifically answer your questions:

  1. scponly is no longer needed or recommended (it’s not dangerous, as far as I know, but it’s not useful). You just need to use ProFTPd for all connections from users (except those you trust to have shell ssh access), and add “DefaultRoot ~” to the configuration.
  2. No, and we still discourage people from using a chroot environment for untrusted users. chroot has security implications that are difficult to reason about. It may be that recent versions of openssh make chroot safer, as it may be able to drop privileges in a safe way today (it probably can, if I’m reading the docs right); historically, even a single mistake in your chroot filesystem could lead to a root privilege escalation vulnerability (which is game over for security). I haven’t done the research to understand how this risk has been mitigated in recent years, as I don’t want to go down that path for security in Virtualmin. There are much better options today, including SELinux.

Also, note that Virtualmin has tighter permissions on home and safer defaults for web apps than other control panels (at least, it did last time I looked at how cPanel and Plesk were doing things). A chroot would provide little actual security benefit and would potentially open up security concerns of its own. On my personal systems, I don’t mind granting untrusted (but not anonymous) users shell access. I’m not worried about them seeing files on my system, because UNIX systems were designed from the ground up to be multi-user systems.

chroot also does not prevent someone with any level of knowledge from seeing files on the filesystem (as they do when logging in without a chroot). There are many ways to see those files in any hosting system, including web applications, procmail recipes, cron jobs (though this can be forced to take on the environment of the chroot at the expense of a more complex chroot), etc. chrooting the shell or FTP provides a false sense of security.

I would like to spend more time with SELinux. It does provide means to do what many people use chroot for, without the problems of chroot. I made Virtualmin work comfortably with SELinux a while back when we built our new boxes on CentOS 7 (it actually wasn’t that hard; took a couple of hours), but haven’t done the work to package up the new rules that are needed yet. But, the standard strict SELinux rule set also does not prevent users from seeing files outside of their home. The stuff that people want chroot for just aren’t security issues, generally speaking…they seem like security issues, but they’re really not.

So, to sum up:

We don’t do chroot because it does not improve security to do chroot. But, you can get the effect of a chroot for FTP and FTP over SSH connections using the DefaultRoot option in ProFTPd. This option is easy, and it is safe.

Oh, also, the new File Manager (Filemin) has this ability as well, and defaults to restricting user to their home (not for security, but for usability).

25

Thank you. Your approach is very professional. I am looking forward for updates.

26

Do you have a working set of SELinux policy that works with virtualmin ?
I tried using selinux minimal policy and adding a few rules / exceptions (logs, apache and mail mostly), it works, but I assume you did a better job :slight_smile: