Re: restrict telnet/ssh but allow ftp

From: Tim Haynes (usenet@stirfried.vegetable.org.uk)
Date: 01/10/03 

From: Tim Haynes <usenet@stirfried.vegetable.org.uk>
Date: Thu, 09 Jan 2003 23:40:53 +0000

unruh@string.physics.ubc.ca (Bill Unruh) writes:

> JustiN <justinallen2@emcs.ca> writes:
>
> ]I'm trying to do this and having next to no luck.
> ]I've seen many suggestions to change the shell location in /etc/passwd
> ]to /dev/null or /bin/false, etc. However when I do that I can't login
> ]with ftp. As soon as I change it back to /bin/bash I can login with
> ]ftp.
> ]How can I accomplish this?
> Make sure you put /bin/false in as one of the shells in /etc/shells

Personal preference: I would use /bin/true for this, as I consider it
answers the question "do they have some form of network access through any
service?". But /bin/false will suffice if you want.

> Well, you can make a chroot jail, but you have to essentially copy almost
> the whole operating system into that subdirectory.

Naaaaaah! A reasonable starting package-list is as follows:

    baselayout bash cracklib fileutils findutils glibc grep gzip ?lynx? man
    man-pages miscfiles ?ncurses? ?netkit-base? ?nvi? ?openssh openssl? pam
    pam-login ?perl? popt ?procps psmisc? readline rsync sed sh-utils
    shadow slang tar textutils util-linux which zlib zsh

Things flagged with `??' around them are more optional than others. With
this little lot, you can get as far as a choice of at least 2 shells for
someone logged into a chrooted environment.

> They need many of the libraries in /usr/lib/ and /lib, so they would need
> to be copied to your chroot jail, and also the binary programs that they
> are allowed to use ( You would not need the lib stuff if you recompiled
> all the programs as static.)

Hmmm. This is one of the areas in which having all your packages available
locally works (either using an automated rpm system, debian's
/var/cache/apt/archives/, or gentoo's /usr/portage/packages/All/
directory). Simply take each of the above in turn and untar it into the
chroot jail. Woopie.

> I however do not know how you tell ssh to created a chroot as part of the
> login.

I would invent a simple fake shell that calls chroot(), hops into the
user's directory within the chroot jail, and spawns bash or whatever
(optionally with commandline arguments if you want scp and/or rsync to
work).

Something like the following will suffice, if you're a trusting sort of
soul ;]

    #!/usr/bin/suidperl

    $ENV{PATH}="/sbin:/bin:/usr/bin:/usr/sbin";

    $ENV{"SHELL"}="/bin/bash";

    chroot("/home/chrootjail");

    $>=5000; #choose your UIDs with care
    $<=5000;
    $(=100; #choose your GIDs with care
    $)=100;

    chdir("/home/username");

    if($#ARGV >= 0) {
      push(@args, "-c");
      push(@args, @ARGV);
      }

    $cmd="/bin/bash";

    map {s/!/!/goi} @args;

    exec($cmd, @args);

Or you could write it in C if you wanted.

Installation:

loginusername:x:5000:5000:Name:/home/chrootjail:/usr/local/bin/chrootsh-gw.pl

and

-rwsr-x--- 1 root 5000 309 Jan 8 22:11 /usr/local/bin/chrootsh.pl*
^^^^^^^^^^^
very important if you don't want everyone on your system to be able to
become the underprivileged user.

The GRSecurity patch provides one or two useful customizations for chroot
jails - there's buffer-overflow protection, restrictions on /proc, denying
of mounts, double-chroots, pivot_root, denying of mknod, restriction of
priority changes, removal of Capabilities, randomization of PIDs, ability
to deny client and/or server sockets to a group, and a few other toys as
well.

With that lot on board, they ain't getting out of there any time soon.

~Tim 

-- 
There's a sadness, there's a joy            |piglet@stirfried.vegetable.org.uk
There's a place,                            |http://spodzone.org.uk/
There's a song that will never die          |
Forever                                     |