Security issue: Virtualmin user can use SSH

Howdy -- while it is intentional that SSH is enabled, users who don't want that can disable it by going into System Customization -> Custom Shells.

You can also setup password restrictions by going into Webmin -> System -> Users and Groups -> Module Config -> Users and Groups, and there, you can setup a variety of things such as "Minimum password length" and "Prevent dictionary word passwords".

By default, a Virtual Server owner can access the system via SSH, FTP, and through Virtualmin itself.

All of those offer the same permissions -- a user using SSH can see and edit the same files as a user using the Virtualmin filemanager. It also doesn't require SSH access to run commands. That can be done via Virtualmin, or a web-based file manager.

The thing preventing them from causing problems are the permissions setup on your server.

There is some additional information on there here in the section "How can I prevent other types of users from browsing the entire filesystem?":

https://www.virtualmin.com/documentation/security/faq

By default, only the root user has the ability to edit files in /etc. No other user can do that.

The only way that would occur is if this user has root privileges, or if the files in /etc have been modified to allow additional users to edit them.

You may need to review the permissions of the files in /etc to ensure that's not the case.

However, for both SSH and SFTP, there isn't a chroot jail for them for the reasons described in the FAQ link.

That is, preventing them from accessing a file in SSH doesn't prevent them from accessing it via the website. So the real key is to make sure that permissions are set in a way that doesn't allow users to view or edit files they shouldn't be able to access.

Hi ADDISON74,

Am interested and subscribing to this to see if you'll be able to implement what you want.

I agree, this idea of putting on the system admin, the responsibility of the properly restrictive file permissions and ownership of the entire server, is probably too much to ask, in 2015. Many or most using Virtualmin, are amateur system admins and cannot properly police every single file and folder on their system. If they make one small mistake, which is easy to do, in permissions/ownership, the entire server or a large part of it, could be compromised, leading to costly data loss. This is relatively easy to prevent from the point of view of Virtualmin. Probably Virtualmin application itself would be best at applying "best practice world class level" secure default permissions and ownership, by default, to the entire server, so as to prevent information leakage, security breach, etc. This problem of leakage leading to much easier hackability of the server, was so huge and important, that Cpanel solved it for their customers by having created their own filesystem virtualization product called CloudLinux, it works by whitelisting only certain binaries, config files, folders, to allow these be accessed by users, via sftp and web/webdav. All others are forbidden. Sort of a chroot plus accessibility of certain whitelisted system conf files and binaries located otuside of the chroot jail. No user should be able to see contents of other user's files, or sensitive system files, even if it would be technically the "fault" of the system admin for not policing proper permissions and ownership. There is too much possible loss of value at stake.

This is a long time issue and based on many similar discussions like:

• http://www.virtualmin.com/node/4677
• http://www.virtualmin.com/node/5747
• http://www.virtualmin.com/node/6454
• http://www.virtualmin.com/node/7720
• http://www.virtualmin.com/node/8480
• http://www.virtualmin.com/node/9379
• http://www.virtualmin.com/node/9823
• http://www.virtualmin.com/node/19196
• http://www.virtualmin.com/node/19289
• http://www.virtualmin.com/node/19659

I concluded long time ago *min developers won't address it. That is why I wrote above to see if you'll be able to implement what you want.

So, in theory we could implement SSH chroot restrictions for Virtualmin, so that domain owners logging in via SSH cannot see anything outside of their home directory.

However, the default permissions prevent users from accessing each others' home directories. Also, all critical files in /etc are locked down by default on all Linux systems to prevent access by non-root users. So I think that the security benefits added by an SSH chroot are minimal..

So I think that the security benefits added by an SSH chroot are minimal.. I cant agree with this. No sane host would allow anyone to get out of their /home and even listing other host (names) would be a security breach.

Other domain names are still going to be visible from files like /etc/passwd though, which are typically included in any chroot so that ls -l shows usernames properly.

Jamie, in fact, what you say (chroot including /etc/passwd) is no longer true on cpanel.

Around the year 2009, cpanel changed their chroot security model so that /etc/passwd is no longer included in chroot.

Therefore, since 2009, when I SFTP log in to my cpanel shared hosting account (equivalent to logging into a virtualmin virtual server), I no longer see username or group on my file and folder ownership.

Instead I see, in my case, user 503 and group 509.

Too bad for my visual convenience, but for the sake of security and privacy, it is more important that I not see my neighbor accounts and/or domain names (which is what I used to be able to see via the chroot having included of /etc/passwd), than to see my own account name.

It's really an issue of privacy...

I hope you can now see the privacy and security value of adding chroot environment for all user logins to the server (FTP, etc).

Here is an article from 2012 about manually setup SFTP + chroot on a time consuming painstaking basis inside Virtualmin.

http://blog.thewebsitepeople.org/2012/10/virtualmin-sftp-chroot/

However in the comments to the blog article above, on 4 days ago, Jim says he doesn't bother with SFTP (via SSH) and simply uses FTPS which is jailed automatically just like FTP.

http://www.virtualmin.com/node/29262

https://www.howtoforge.com/tutorial/proftpd-tls-installation-ubuntu-15-04/

This still doesn't get around the need to jail the SSH shell for "normal" users to keep from leaking sensitive privacy related information from system areas, such as, lists of other users and domains on the system, etc.

Seems like there are plenty of other ways that information about which domains and accounts exist on the system could still leak though - such as running processes, visible using the ps auxwww command.

What can be modified with other things like grsecurity.net what is usually used in shared hosting.

So it absolutely should not be possible to access the directories of other domains - either via SSH or from a PHP script. The default Virtualmin install runs PHP scripts using fcgid, which runs them as the domain owner. The only exception to this case is if you switched domains to mod_php execution mode.

Jamie,

To say frankly, I don't understand why you are so much opposed against jailing regular users into their home directories. Even if there are other ways for really experienced hackers to get to sensitive information, it would be still nice to limit regular users form seeing other users' usernames, etc. I don't see any harm from providing minimum privacy and security implementation.

Maybe it complicate other things in Virtualmin and that's why you are reluctant to address this really really long going issue? If so say so. I mean your stance "there other ways to see sensitive information" does not justify refusing this request. It would be beneficial for Virtualmin to have a possibility to jail users within their home directories despite existence of whatever ways to see sensitive information.

The reason I'm opposed is that it adds a lot of complexity to Virtualmin to maintain a chroot jail for each user - so support SSH logins, a whole bunch of commands and libraries have to be copied or bind-mounted inside the chroot. So unless there is a big security benefit from doing this, I'm not convinced that it is worth the extra complexity.

Also, for any SSH chroot to be effective, the chroot has to apply to CGI and PHP scripts as well - otherwise a domain owner can simply upload a script that displays the contents of /etc/passwd or whatever.

Sorry to dive in late in this thread...but I have strong opinions on this issue. ;-)

So, I hear folks frustration. And there's quite a bit of misunderstanding about what is currently easy to do, what is currently hard to do, and what a chroot would gain.

First up: default permissions on a Virtualmin system are much tighter than has been alluded to. If any user can see any other users data, the permissions on their home directory are definitely not defaults. It isn't hard to get permissions right...just leave them at the default.

Next up: I'm almost convinced it's worth making things tighter by default, but I'm still pretty certain chroot is not the right way to handle the goal of further tightening privacy on the system. SELinux probably is, and we would definitely consider adding more support for SELinux related features to Virtualmin.

It is already possible (very easily) to lock users into their homes in ProFTPd using DefaultRoot. And ProFTPd supports FTP over SSH, so it can be made the only method that users you want to restrict in this way login.

The thing about chrooting ssh is that it only prevents one method of seeing the file system. It sounds like cPanel has gotten somewhat more clever about their chroot build since I last researched it, but it doesn't alter the fact that it is a false sense of security. Short of giving every user a private chrooted Apache instance, there will be several methods of easily reaching the filesystem with whatever permissions web apps run with. If cPanel prevents that, I'd be curious about how. The ssh chroot has no relation to this and would not be how they're doing it.

I should probably look at a current cPanel system to get on the same page with what y'all are seeing and asking for. Last time I looked there were simple ways to see all of the information you can see on a Virtualmin system on a chroot enabled cpanel system (not via ssh, but via Apache, and other services that operated either outside of the chroot or within their own chroot with more access than users had). Y'all got one I can check out?

In short: I worry you're hearing us say "we don't want to make Virtualmin more secure or more respectful of privacy by default", but what we're really trying to express is "we don't want to make the same mistakes as cPanel or provide a false sense of security in doing so".

We can talk about ways to improve security. We just don't believe chroot is that way.

After sleeping on it, I'm looking into chroot shells again. Last time I looked into it there were serious security implications that made it such that it would have been irresponsible for us to make it an easy thing to setup (specifically, an exploit of the jail could lead to root escalation in the past; which is the worst possible outcome, especially for something that people believe provides "security"). That seems to no longer be a major risk, and privilege separation works alongside chroot with modern OpenSSH versions, so my biggest concern is not so much a factor any more.

I still worry at the belief that chroot provides significant security benefits in this context. But, it seems to be something that a lot of people want, so once the new website launches and the new major version of Virtualmin comes out (in a few days), I'll dig back into this issue.

What cpanel does to acheive this is with code they call cloudlinux, it's a file system driver that virtualizes the file system and returns contents of files but only if they're on a whitelist.

By doing this you save on all that wasted disk space of having to actually copy hundreds or possibly thousands of files into each virtual server account's chroot. The driver returns the contents of that one file as long as the system allows it.

Whatever files are essential are allowed.

Whatever compromises security (/etc/passwd , files in your neighbor's virtual server, the very existence of your neighbor's virtual sever, your neighbor's running processes, etc..) is non existent according to the file system driver, and therefore invisible to you.

This is like a "linked" chroot instead of an "embedded" chroot.