ChrootDirectory per SSH Subsystem?

John Olsson M john.m.olsson at ericsson.com
Fri Jan 20 03:16:01 EST 2012


> Place a couple of wrappers around the commands, doing the chroot for you?

Hmmm. I'm not sure I follow you. Our command shell (which is not like a standard *nix shell) needs to operate in a non-chrooted environment. But the file system shown by the SFTP subsystem needs to operate in a chroot:ed environemnt and only expose that subset of directories and files.


I think it is time to provide a bit more information now. :)

Lets call our own shell "cliss" and basically only users defined in an LDAP server is allowed to log on to port 22 (on another port we provide access to the Linux system, but only for locally defined users). We have extended the standard LDAP schema an additional attribute representing "roles"** and a user can be assigned one or more of them. The cliss shell provides a prompt from which an "information model" can be manipulated via transactions (much like routers works today) and setting/toggling an attribute results in actions happening on the machine. Access to the diferent parts of the information model is controlled via the roles stored in the LDAP server for the user (a role can give you either read-access or read/write-access to an one ore more object(s) or attribute(s) in the model).

The information model will also provide a file system view (the virtual filesystem mentioned earlier) where access control is controlled via the roles. Since we need to transfer files to and from the machine we also need to provide an SFTP view of the virtual filesystem and this is done via FUSE (since we need to enforce the role access rights and not by uid and/or gid).

Due to that cliss needs to be able to access all of the Linux file system (you do *all* configuration of the machine (basic stuff like IP-address and net mask as well as application specific things) via the information model), but at the same time should SFTP only expose the same virtual filesystem as found in the information model.


Additionally we have the restriction that port 22 _must_ be used for both SFTP access and cliss.


Based on this, what do we need to do to achive this? Is there some tricky way to configure the OpenSSH server or do we have to patch the source code? If the latter case, is this concept of being able to specify Chroot-jail per SSH subsystem something that is acceptable to include in standard OpenSSH server configuration file?


** Due to that we can not assume anything about the meaning of a certain GID we can not use them, instead we have the role concept where we can guarantee the meaning and thus build security across a vast number of machines from that. But otherwise there is really no difference between GID and role.

-----Original Message-----
From: Ángel González [mailto:keisial at gmail.com] 
Sent: den 19 januari 2012 16:39
To: John Olsson M
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: ChrootDirectory per SSH Subsystem?

On 19/01/12 14:38, John Olsson M wrote:
> Hi,
>
> According to the sshd_config manual page the option ChrootDirectory can be used to force a chroot:ed environment for the SSHD server. But as I understand the manual page this is a global setting and it is not possible to specify this per SSH subsystem.
>
> We are building a system where we need users to be able to log on from remote machines via SSH, but with the tweaks that we (for security reasons) for SFTP-sessions only want to show a virtual filesystem and "standard" SSH subsystem leads to our own shell offering only our own commands. Unfortunately, there is a conflict between what we want to show via an SFTP session and what the shell needs to be able to access.
>
> What is your take on this? Is getting the desired behavior above an RTFM? Or are we entering the land of patching the source code? If the latter, do you have feeling for if is a small or huge undertaking (both implementing and maintaining)?
>
> Would such an enhancement be something that could be accepted into the main development trunk, or do you have concerns over the concept of being able to override the global setting per SSH subsystem?
>
>
> /John
Place a couple of wrappers around the commands, doing the chroot for you?



More information about the openssh-unix-dev mailing list