News Group Posts

setup chroot jail ftp

Main Index

From: brian@aljex.com
Subject: Re: FTP guest access chroot not working
Date: 23 Mar 2005 03:47:33 -0800
Message-ID: <1111578453.686427.252130@g14g2000cwa.googlegroups.com> 
References: <1111532063.748679.264480@f14g2000cwb.googlegroups.com> 

Not sure what you are missing, but I have this working on a 5.0.6 box
with the stock ftp server, so I'll just go through my entire setup and
maybe you can compare against your own and spot the problem. Pay
attention to such things as the ownership & permissions modes on
various files & dirs.

I thing the MAIN secret was an incorrect man page that described a
certian option as being on by default and really it's off by default
and you have to edit /etc/inetd.conf and tcp stop ; tcp start to get
the change into effect.


Then you still have the normal non-trivial list of things you must set
up just right.

if I don't mention a files perms or paste a ls output, then it
generally means it's a file that was already there and I just edited
it.

the user name is "someguy"
I have modified /etc/default/accounts so that users home dirs are in
/home, yours will be in /usr
the "root" dir for the chroot is /home/someguy/ftp

I don't claim that every one of these is necessary or even correct,
only that it's what I see on my working box. As we all know, a thing
can work enough to seem fine and still be wrong...

-----
/etc/shells includes:
/bin/false
-----
/etc/passwd includes:
someguy:x:456:102::/home/someguy/./ftp:/bin/false
-----
/etc/group includes:
someguy::102:someguy
-----
/etc/inetd.conf includes:
ftp     stream  tcp     nowait  root    /etc/ftpd       ftpd -a -d -i
-l -L -o -X
-----
/etc/ftpaccess includes:
# chroot ftp users
guestgroup      someguy someotherguy yetanotherguy
-----
ls -lR /home/someguy:
total 20
-rw-------   1 someguy group       1193 Nov 19 09:35 .kshrc
-r--------   1 someguy auth           0 Nov 19 09:36 .lastlogin
-rw-------   1 someguy group          6 Nov 19 09:36 .profile
dr-xr-xr-x   2 root     sys          512 Nov 23 10:34 bin
drwxr-xr-x   2 root     sys          512 Nov 23 10:50 dev
dr-xr-xr-x   2 root     sys          512 Nov 23 12:43 etc
drwxrwxrwx   2 someguy someguy    1024 Mar 23 03:09 ftp
dr-xr-xr-x   2 root     sys          512 Nov 23 10:42 lib
dr-xr-xr-x   2 bin      bin          512 Nov 23 12:22 shlib
dr-xr-xr-x   3 root     sys          512 Nov 23 10:44 usr

/home/someguy/bin:
total 88
---x--x--x   1 root     sys        43660 Nov 23 10:34 ls


/home/someguy/dev:
total 0
crw-rw-rw-   1 root     sys       35,  0 Jul 22  2004 socksys
crw-rw-rw-   1 root     root      23,  0 Jul 22  2004 zero

/home/someguy/etc:
total 4
-r--r--r--   1 root     sys           23 Nov 23 12:43 group
-r--r--r--   1 root     sys           30 Nov 23 12:43 passwd

/home/someguy/ftp:
total 412
-r--------   1 someguy auth           0 Nov 23 16:06 .lastlogin
[...411 data files that this user has uploaded...]

/home/someguy/lib:
total 370
-r-xr-xr-x   1 bin      sys       188312 Nov 23 10:42 libprot.so.1

/home/someguy/shlib:
total 136
-r-xr-xr-x   1 root     sys        67751 Nov 23 12:22 libc_s

/home/someguy/usr:
total 2
dr-xr-xr-x   2 root     sys          512 Nov 23 10:47 lib

/home/someguy/usr/lib:
total 3694
-r-xr-xr-x   1 bin      sys       562076 Nov 23 10:45 libc.so.1
-r-xr-xr-x   1 bin      sys       537324 Nov 23 10:47 libresolv.so.1
-r-xr-xr-x   1 bin      sys       240228 Nov 23 10:46 libsocket.so.1
-r-xr-xr-x   1 bin      sys       537324 Nov 23 10:46 libsocket.so.2
-----
cat /home/someguy/etc/passwd:
someguy:x:456:50::/:/bin/ksh
-----
cat /home/someguy/etc/group:
someguy::102:someguy
-----
cat /home/someguy/.profile
exit
-----

all those files / directories / files I listed under /home/someguy were
either created by the initial useradd -m command, created manually
according to the TA found on the sco web site, or copied from the
equivalent place in the base OS. Note: when you copy those files, you
need to copy the real files, not the symlinks!
example: the base OS "/bin/ls" is really just a symlink to
/opt/K/SCO/Unix/5.0.6Ga/bin/ls
so when creating the new chroot env, I used the tar command with the -L
option and a little "files" file as a quicky way to gather all the
necessary files, pasted right from that TA, and get the directories
created all in one easy, repeatable, shot.
ie:
jailfiles:
----
/bin/ls
/etc/passwd
/etc/group
/lib/libprot.so.1
/usr/lib/libc.so.1
/usr/lib/libsocket.so.1
/usr/lib/libsocket.so.2
/usr/lib/libresolv.so.1
/dev/socksys
/dev/zero
/shlib/libc_s
-----
and then ran:
tar cvLfF - jailfiles |compress -H >jail.tar.Z
cd /home/someguy
zcat /jail.tar.Z |tar xvAf -

It's possible I used cpio instead or maybe had to manually create the
/dev files with mknod.


And I think that's it.

I see one discrepency right off, the users group in the users chrooted
copy of /etc/passwd doesn't match anything else, but, it doesn't seem
to be impacting anything we happen to care about.

The user can upload/download files at will in his chroot jail, and
cannot get out of that jail.
When you log in as this user, you can see /usr /etc /usr/bin /usr/lib
etc... but it's only the skeleton copy in the chroot jail not the real
ones. if you created a symlink inside the jail that points to some real
file outside the jail, then when your are logged in via ftp, the file
is just a broken link, you really do not have any access to anything
outside that jail.

Additionally, this is a ftp-only account. The user cannot login via
telnet or ssh or facetwin.

enjoy :)

If that was too easy then come back for round 2, I have also set up
chroot jailed sftp-only accounts on 506 using a patched version of
openssh. they can't even ftp in, *only* sftp, only protocol-2, only
blowfish, only dsa keys. Of course the same users who demanded "make it
ultra ultra secure!!!" did nothing but complain how "complicated" it
was to get an sftp client and ssh keys set up ...

Brian K. White  --  brian@aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani
 

3 comments

Click here to add your comments




Wed Apr 9 18:38:34 2008:   gary


great article. I am having a problem with my own chroot environment. I have users who must use a jailed FTP and I have users who must use ftp over ssh, however, when using ftp over ssh with the jail, they can navigate out of their folders and view other files. This is a big problem for me, and was wondering if you might have some insight as to what might be the cause. I'm running proftpd, linux debian 2.6.18. I followed the perfect debian setup guide and managed to get it working perfectly for a bit, but it seems as though in the process of either setting up BIND or restarting a service or two, the jail for SSHFTP has broken.



Wed Apr 9 19:41:58 2008:   TonyLawrence


I don't know the answer to your problem, but I know I hate FTP..





Wed Apr 9 20:14:41 2008:   gary


for future reference, to limit users getting out of their jail and digging through other folders, chmod o-r /foldername on all the folders in your chroot/jail will keep non root / non owners out of the folders. i've used this as a temporary fix till i figure out my broken jail. just fyi.

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.