Does anyone know how to do a chroot for users logging in via SSH ? You know, like the chroot that can automatically be done when ftp'ing onto the server. I don't want the users to be able to escape from their homedirs to higher levels in the directory-tree. I know that this can be done somehow, but couldn't find any hint on the net nor in any howto. Thanks in advance. Stephan --- Stephan M. Ott // OKDesign oHG Internet-Providing / Netzwerkmanagement smo@okdesign.de ..... http://www.okdesign.de tel. 09565-61397 ..... fax. 09565-61399 handy. 0171-8351130 oder 0171-7858064
On Wed, 20 Oct 1999, Security Webmaster OKDesign oHG wrote:
Does anyone know how to do a chroot for users logging in via SSH ? You know, like the chroot that can automatically be done when ftp'ing onto the server. I don't want the users to be able to escape from their homedirs to higher levels in the directory-tree. I know that this can be done somehow, but couldn't find any hint on the net nor in any howto. Thanks in advance.
Stephan
Doing chroot to ssh session would leave the session virtually useless, as the users then obviously would not have access to any system commands (as most of them are not in their homedirectories). I would rather protect the directories & files with normal file access rights. Read man chmod first. -Pete
--- Stephan M. Ott // OKDesign oHG Internet-Providing / Netzwerkmanagement smo@okdesign.de ..... http://www.okdesign.de tel. 09565-61397 ..... fax. 09565-61399 handy. 0171-8351130 oder 0171-7858064
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Secured file and directory permissions are good, but I would love to restrict my users to a 'jail' virtual root. Create a new root directory at /jail and move all of thier home directories there as well as copies of system binaries. Then you could symlink the orignal directories back to the chrooted ones and maybe even symlink the jail bin directory to the system one. Hence you get full functionality is a chrooted environment, the problem is HOW DO YOU DO THIS WITH SSH (outside of patching the code, which is probably trivial). -HD "Petri Sirkkala." wrote:
Doing chroot to ssh session would leave the session virtually useless, as the users then obviously would not have access to any system commands (as most of them are not in their homedirectories). I would rather protect the directories & files with normal file access rights. Read man chmod first.
Quoting H D Moore (secureaustin@consultant.com) on Thu, Oct 21, 1999 at 09:24:06AM -0500:
Secured file and directory permissions are good, but I would love to restrict my users to a 'jail' virtual root. Create a new root directory at /jail and move all of thier home directories there as well as copies of system binaries. Then you could symlink the orignal directories back to the chrooted ones and maybe even symlink the jail bin directory to the system one. Hence you get full functionality is a chrooted environment, the problem is HOW DO YOU DO THIS WITH SSH (outside of patching the code, which is probably trivial).
Give them a chroot shell. Should be 10 lines of code at max. I am busy with atrade show right now, if none else comes up with an example, remind me next week and I start digging. cheers afx -- SuSE Muenchen GmbH Phone: +49-89-42769-0 Stahlgruberring 28 Fax: +49-89-42017701 D-81829 Muenchen, Germany May the Source be with you!
Hi, H D Moore wrote:
Secured file and directory permissions are good, but I would love to restrict my users to a 'jail' virtual root. Create a new root directory at /jail and move all of thier home directories there as well as copies of system binaries. Then you could symlink the orignal directories back to the chrooted ones and maybe even symlink the jail bin directory to
symlinking is not enough, you must hardlink them
the system one. Hence you get full functionality is a chrooted environment, the problem is HOW DO YOU DO THIS WITH SSH (outside of patching the code, which is probably trivial).
the following is not tested, but may work: create a user (here uid 1123) with a login shell "/bin/jailshell", jailshell.c could look like this: #include <unistd.h> main(argc, argv) int argc; char** argv; { chroot("/jail"); setuid(1123); system("/bin/bash"); } compile it (gcc -o jailshell jailshell.c) chown root jailshell chmod 4555 jailshell disallow .shosts/.rhosts and password authentication, only allow RSA-Authentication: put into /etc/sshd_config: IgnoreRhosts yes RhostsAuthentication no PasswordAuthentication no KerberosAuthentication no RSAAuthentication yes create a key (ssh-keygen) on the host where the user comes from restrict the commands users with certain keys can execute to jailshell: put the public key in .ssh/authorized_keys command="/bin/jailshell",no-port-forwarding the_public_key.... see 'man sshd', especially the section 'AUTHORIZED_KEYS FILE FORMAT' Ciao, Robert -- Robert Hoffmann Robert.Hoffmann@consol.de ConSol* Software GmbH http://www.consol.de Franziskanerstr. 38 Tel: +49-89-45841-294 81669 Muenchen Fax: +49-89-45841-111 Tel. (BMW): +49-89-382-45889
On Fri, 22 Oct 1999, Robert Hoffmann wrote:
Hi,
H D Moore wrote:
Secured file and directory permissions are good, but I would love to restrict my users to a 'jail' virtual root. Create a new root directory at /jail and move all of thier home directories there as well as copies of system binaries. Then you could symlink the orignal directories back to the chrooted ones and maybe even symlink the jail bin directory to
symlinking is not enough, you must hardlink them
the system one. Hence you get full functionality is a chrooted environment, the problem is HOW DO YOU DO THIS WITH SSH (outside of patching the code, which is probably trivial).
the following is not tested, but may work:
create a user (here uid 1123) with a login shell "/bin/jailshell", jailshell.c could look like this:
#include <unistd.h> main(argc, argv) int argc; char** argv;
{ chroot("/jail"); setuid(1123); system("/bin/bash"); }
Big mistake. You missed the chdir() after the chroot().
compile it (gcc -o jailshell jailshell.c) chown root jailshell chmod 4555 jailshell
disallow .shosts/.rhosts and password authentication, only allow RSA-Authentication: put into /etc/sshd_config: IgnoreRhosts yes RhostsAuthentication no PasswordAuthentication no KerberosAuthentication no RSAAuthentication yes
create a key (ssh-keygen) on the host where the user comes from
restrict the commands users with certain keys can execute to jailshell: put the public key in .ssh/authorized_keys
command="/bin/jailshell",no-port-forwarding the_public_key....
see 'man sshd', especially the section 'AUTHORIZED_KEYS FILE FORMAT'
Ciao, Robert
-- Robert Hoffmann Robert.Hoffmann@consol.de ConSol* Software GmbH http://www.consol.de Franziskanerstr. 38 Tel: +49-89-45841-294 81669 Muenchen Fax: +49-89-45841-111 Tel. (BMW): +49-89-382-45889
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
Security Webmaster OKDesign oHG wrote:
Does anyone know how to do a chroot for users logging in via SSH ? You know, like the chroot that can automatically be done when ftp'ing onto the server.
Search for the Virtual Services How-To by Brian Ackermann (brian@nycrc.net). It includes some examples (which, however, have to be adapted to work with Linux) how to "virtualize" all daemons and services. In principle it uses getsockname() to determine which IP is being accessed, then reads the virtual info from a configuration file to chroot() to the defined directory and hand over the connection to the service. In conjunction with inetd, virtuald can virtualize any service (with more or less changes). I tried pop3, telnet, ssh, ftp and some more, and it was hard (impossible?) to discover that you are connected only on a virtual server, not a stand-alone-machine. Even "virtual root" on a virtual machine cannot escape the chroot (must be fun to watch the virtual r00t on a compromised machine ;-) ). This means, that you have to have IP-aliases up and running and need to copy some directory trees (/bin, /usr/bin, /etc (don't use your main /etc!) ...) into the virtual machines to give your users a full working environment. A "naked" virtual machine here took up about 50MB, not too much regarding the average size of HDDs nowadays... ;-). I recommend a profound knowledge of what you are doing and how the whole thing works. virtuald is great as a security concept, but it's easy to mess things up. regards, Alexander Wolf
participants (7)
-
Alexander Wolf -
Andreas Siegert -
H D Moore -
Petri Sirkkala. -
Robert Hoffmann -
Security Webmaster OKDesign oHG -
Thomas Biege