Jailed SSH?

[pixelstore]

Hey guys! I'm currently trying out CPanel as I'm thinking about moving from Plesk.

In Plesk I have a option under the settings for an account that says "Chrooted" for SSH access. When choosing this mode the user is jailed to his home directory and can't browse anything below it. Also the commands are very restricted and only allows about 100 of them.

In Cpanel I've set the user account to "Jailed Shell" but I don't see any different really. I have 1257 commands to use, and when logged in as root I have 1279 commands. Also I can browse below my home directory and even list /.

Isn't there any settings to jail the SSH user to a certain amount of commands and of course their home directory?

I use GIT to update all my clients on the server so I need SSH access.

[pixelstore]

Anyone? This must be a common problem? Why would you like your clients to have such large access to your server?

[alexio]

Am also experiencing this - and certainly pixelstore and myself can't be the only ones.

A simple test for anyone allowing Jailed shell:

Log into the (supposedly) jailed acocunt, and type:
cd /var
and then :
ls

You should now see the contents of the /var folder... e.g.:.

./ ../ cpanel/ lib/ log/ run/ spool/
youraccount@whatevr.com [/var]#


Jailed ... with Freedom
A quizzical paradox.

[pixelstore]

Yeah exactly, I don't see any different between jailed and a normal shell

[cpCharlesB]

Hello,

Giving each user their own chroot would not be a very good idea and would not improve security on your server.

(1) This is giving root access to each user, within their chroot, enabling them to install/remove packages within their chroot that could cause their account break completely and become impossible to recover/fix. Repairing mistakes done in public_html for 100 users on a webserver is bad enough, now imagine maintaining 100 separate complete Linux environments -- each running its own instance of Apache/Perl/SQL and anything else the user wants.

(2) Sometimes daemon processes such as apache will run within their own chroot, the reason being that if Apache is compromised -- then only the chroot is at risk of being rooted, not the entire server. However, you would not want to have Apache serving files out of a million chroot environments (each of which, for all you know, could be running its own conflicting webserver software).

(3) You don't get much added security from this, there are plenty of ways for users to escape from their chroot and (intentionally or otherwise) damage the host system for their chroot. For example, setting the hostname in a chroot will also change the hostname of the server and cause downtime. It is also a common problem in chroots that modifications to the kernel or core GNU system libraries (glibc) made within a chroot will also take place in the host environment.

The intended uses of a chroot are:

* To create a testing environment for software development in a clean isolated environment within a stable system, without making any changes to the host environment.

* To "jail" certain background processes for security reasons or otherwise. (This is more common in the BSD world)

* To cross-compile software for a system whose processor architecture is different from the host, without modifying the toolchain of the host. For example, to build an ARM binary on an x86_64 machine -- you could have a chroot with the gcc ARM toolchain installed and build a program in the chroot without potentially causing dependency or library version conflicts within your host system.

That said, you can create custom jailed shells within cPanel/WHM -- but it is important to understand that this is *not* a chroot!

Creating Custom Jailed Shell (Jailshell) Mounts

Also, if your system is correctly configured, users should have write access only within their home directory and limited read access elsewhere in the file system. Unix is relatively secure by design.

[pixelstore]

Hello,

Giving each user their own chroot would not be a very good idea and would not improve security on your server.

(1) This is giving root access to each user, within their chroot, enabling them to install/remove packages within their chroot that could cause their account break completely and become impossible to recover/fix. Repairing mistakes done in public_html for 100 users on a webserver is bad enough, now imagine maintaining 100 separate complete Linux environments -- each running its own instance of Apache/Perl/SQL and anything else the user wants.

(2) Sometimes daemon processes such as apache will run within their own chroot, the reason being that if Apache is compromised -- then only the chroot is at risk of being rooted, not the entire server. However, you would not want to have Apache serving files out of a million chroot environments (each of which, for all you know, could be running its own conflicting webserver software).

(3) You don't get much added security from this, there are plenty of ways for users to escape from their chroot and (intentionally or otherwise) damage the host system for their chroot. For example, setting the hostname in a chroot will also change the hostname of the server and cause downtime. It is also a common problem in chroots that modifications to the kernel or core GNU system libraries (glibc) made within a chroot will also take place in the host environment.

The intended uses of a chroot are:

* To create a testing environment for software development in a clean isolated environment within a stable system, without making any changes to the host environment.

* To "jail" certain background processes for security reasons or otherwise. (This is more common in the BSD world)

* To cross-compile software for a system whose processor architecture is different from the host, without modifying the toolchain of the host. For example, to build an ARM binary on an x86_64 machine -- you could have a chroot with the gcc ARM toolchain installed and build a program in the chroot without potentially causing dependency or library version conflicts within your host system.

That said, you can create custom jailed shells within cPanel/WHM -- but it is important to understand that this is *not* a chroot!

Creating Custom Jailed Shell (Jailshell) Mounts

Also, if your system is correctly configured, users should have write access only within their home directory and limited read access elsewhere in the file system. Unix is relatively secure by design.

Thanks alot for the explanation!

What I don't understand is, like in Plesk that I'm used to, you are also limited to the a certain amount of commands. There's only to standards like cd, ls, mkdir etc. And you are locked to your home dir. I can't understand how you could change hostname etc. But still, I see there's more disadvantages as well like with Apache running extra daemons. I don't know if Plesk has solved this, anyhow I haven't noticed any problems with it.

And, yeah, unix is pretty safe as default, but I don't like the idea that a user can list my /home to see all my other clients I have.

Any how, what I'm really after is to use GIT. So my plan was to jail the user to their home and then just limit them to the git-commands and maybe like cd, ls and mkdir. That's it. But maybe someone else has a total other solution for this?

[cpCharlesB]

Thanks alot for the explanation!

What I don't understand is, like in Plesk that I'm used to, you are also limited to the a certain amount of commands. There's only to standards like cd, ls, mkdir etc. And you are locked to your home dir.

The commands are probably disabled by using chmod to change their permissions, but this is usually trivial to bypass.

Suppose "touch" is disabled for users other than root (meaning it has 0754 permissions). Here is how you can still create a file:

armadill[~]$ ls -l test
ls: cannot access test: No such file or directory

armadill[~]$ touch test
bash: /bin/touch: Permission denied

armadill[~]$ > test

armadill[~]$ ls -l test
-rw-rw-r-- 1 armadill armadill 0 Aug  4 10:23 test

Suppose that /bin/chown also has 0754 permissions, here is a similar workaround:

armadill[~]$ ls -l /bin/chown
-rwxr-xr-- 1 root root 53640 Jun 22 06:46 /bin/chown

armadill[~]$ cp /bin/chown .

armadill[~]$ chmod 0755 chown

armadill[~]$ ./chown
./chown: missing operand
Try `./chown --help' for more information.

I think they set the permissions on programs other than 'ls' and 'cd' to prevent users from accidentally doing something dangerous to their own data, rather than under the (false) notion that this provides any additional security.

(Thanks to cPanelJeff for this example!)

http://forums.cpanel.net/f185/how-pr...ml#post1194351

I can't understand how you could change hostname etc. But still, I see there's more disadvantages as well like with Apache running extra daemons. I don't know if Plesk has solved this, anyhow I haven't noticed any problems with it.

From the 'chroot' man page:

chroot() changes the root directory of the calling process to that specified in path. This directory will be used for pathnames beginning with /. The root directory is inherited by all children of the calling process.

Only a privileged process (Linux: one with the CAP_SYS_CHROOT capability) may call chroot().

This call changes an ingredient in the pathname resolution process and does nothing else.

This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a "chroot jail" by doing:

mkdir foo; chroot foo; cd ..

This call does not close open file descriptors, and such file descriptors may allow access to files outside the chroot tree.

FreeBSD project came up with an improvement on chroot (called a "jail") that overcomes many of the fundamental limitations and problems one encounters with an old-fashioned chroot.

Introduction

From the FreeBSD handbook:

The chroot(8) utility is good for easy tasks, which do not require a lot of flexibility or complex and advanced features. Since the inception of the chroot concept, however, many ways have been found to escape from a chrooted environment and, although they have been fixed in modern versions of the FreeBSD kernel, it was clear that chroot(2) was not the ideal solution for securing services. A new subsystem had to be implemented.

This is one of the main reasons why jails were developed.

Jails improve on the concept of the traditional chroot(2) environment, in several ways. In a traditional chroot(2) environment, processes are only limited in the part of the file system they can access. The rest of the system resources (like the set of system users, the running processes, or the networking subsystem) are shared by the chrooted processes and the processes of the host system. Jails expand this model by virtualizing not only access to the file system, but also the set of users, the networking subsystem of the FreeBSD kernel and a few other things.

A FreeBSD jail is similar in some ways to a virtual machine (except it does not do virtualization of hardware and runs on the same kernel as the host)

A jail is characterized by four elements:

A directory subtree -- the starting point from which a jail is entered. Once inside the jail, a process is not permitted to escape outside of this subtree. Traditional security issues which plagued the original chroot(2) design will not affect FreeBSD jails.

A hostname -- the hostname which will be used within the jail. Jails are mainly used for hosting network services, therefore having a descriptive hostname for each jail can really help the system administrator.

An IP address -- this will be assigned to the jail and cannot be changed in any way during the jail's life span. The IP address of a jail is usually an alias address for an existing network interface, but this is not strictly necessary.

A command -- the path name of an executable to run inside the jail. This is relative to the root directory of the jail environment, and may vary a lot, depending on the type of the specific jail environment.

Jails were one of the attractive features in FreeBSD and its variants, but it was ported to Linux pretty quickly.

Jail - Gentoo Linux Wiki

And, yeah, unix is pretty safe as default, but I don't like the idea that a user can list my /home to see all my other clients I have.

They should not be able to ls your /home directory, just their subdirectory of /home.

armadill[~]$ stat /home
  File: `/home'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 28h/40d Inode: 94666843    Links: 10
Access: (0711/drwx--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-08-04 04:02:05.000000000 -0500
Modify: 2012-08-04 01:21:10.000000000 -0500
Change: 2012-08-04 01:21:10.000000000 -0500

armadill[~]$ pwd
/home/armadill

armadill[~]$ ls
access-logs  etc  mail  perl5  public_ftp  public_html  test  tmp  www

armadill[~]$ ls /home
ls: cannot open directory /home: Permission denied

Permission is denied for the user to see the contents of home because the permissions are 0711 and it is owned by root.

Any how, what I'm really after is to use GIT. So my plan was to jail the user to their home and then just limit them to the git-commands and maybe like cd, ls and mkdir. That's it. But maybe someone else has a total other solution for this?

The user should not be able to write outside of their home directory, so they could only 'git clone' to their home directory.

I am sure there are other threads on setting up git on a cPanel server.