Secure File Transfer & Jailed user accounts

[Bryan.ONeal at asu.edu]

I was using the sftpd that comes with openssh, which, as I understand it, does
not offer chroot in and of it's self.  As far as what commands the users need,
their will only be about three people who will need to actually login, and since
they are all employees with virtually unrestricted access to the windows server,
I think ACL and a good sudo file will bee all I need for these guy (Though I
would like more security, but I also would like a solid gold toilet, but neither
may really be worth the resources required to obtain them)

I will go through this tutorial over this weekend and will let you know...  I
may need to meet with you though, thanks for the offer :)

Quoting Joseph Sinclair <plug-discuss at stcaz.net>:

> Assuming you're using the vsftpd for the FTP daemon, you can set the
> users' FTP access to chroot into their home directory.
> From the manpage for vsftpd.conf:
>        chroot_local_user
>               If set to YES, local users will be (by default) placed in
> a chroot() jail in their home directory after login.  Warning: This 
> option  has
>               security  implications, especially if the users have
> upload permission, or shell access. Only enable if you know what you are
> doing.  Note
>               that these security implications are not vsftpd specific.
> They apply to all FTP daemons which offer to put local users in chroot()
>  jails.
> 
>               Default: NO
> 
> To prevent a user from logging in (but still allow FTP), you would
> usually set their shell to /bin/false.
> 
> For the users who login, rbash doesn't really work, since it just turns
> off some commands, and as you noticed, a simple shell script can bypass
> it (just have the script run bash, and you end up in an unrestricted
> shell).
> 
> The best solution for your needs probably is a chroot environment.  To
> do this, you would need to carefully determine all of the command the
> users need, and ensure that those commands exist in the chroot
> environment.
> 
> It's not terribly difficult, but it will take a bit of time.  Once
> you're sure of the environment, you should lockdown the /bin, /lib, and
> other executable directories,
> then set the users' shells to "/usr/sbin/chroot /home/userhome
> /bin/bash" or something equivalent.
> 
> If you're still having trouble, you could drop by the installfest
> tomorrow or contact me off-list to discuss.
> 
> ==Joseph++
> 
> P.S. Here's a link to basic instructions for setting up vsftpd to use
> chroot to jail local logins:
> http://nwc.securitypipeline.com/howto/showArticle.jhtml?articleId=15306130&pgno=2
> 
> Note also, the warning about security in the manual page is because it's
> not terribly hard to break out of a chroot jail if one has the ability
> to upload and execute files.
> It's much harder if the system is FreeBSD, since the chroot() system
> call on FreeBSD is more secure than the POSIX version, FreeBSD also has
> the jail() system call which is even more restrictive.
> 
> 
> Bryan.ONeal at asu.edu wrote:
> > I am using ssh & sftp now, and FileZilla is handling sftp quite well
> > (http://sourceforge.net/projects/filezilla/) however, the users can
> just keep
> > going up the chain, I want to ensure that a user can never go beyond
> their home
> > directory.  Hence the chroot jail approach.  Is there another way to
> restrict
> > sftp access to a home directory?
> > 
> > In addition, is their a way I can allow sftp access, but not shell
> access (as
> > all but about three of the remote users will ever need shell access)
> > 
> > 
> > 
> > Quoting "der.hans" <PLUGd at LuftHans.com>:
> > 
> > 
> >>Am 26. Aug, 2005 schwätzte Bryan.ONeal at asu.edu so:
> >>
> >>
> >>>Ok at this point I am willing to do anything, including wiping out
> my
> >>
> >>OS and
> >>
> >>>starting from scratch.
> >>>
> >>>I need a way for users to access my box in a secure manor and upload
> /
> >>
> >>download
> >>
> >>>files.  But I also need to ensure that those users can never
> navigate
> >>
> >>above
> >>
> >>>their home directory (I will have several users set to the same
> >>
> >>home)
> >>
> >>>I can not get chroot to work for the life of me!
> >>
> >>It's a good idea, but it's not necessary.
> >>
> >>I'd suggest looking into a restricted shell. For instance, there's
> rbash
> >>(
> >>look for it in the bash man page ).
> >>
> >>I'm worried about one part, though.
> >>
> >>###
> >>       When a command that is found to be a shell script is executed
> >>(see
> >>COM‐
> >>       MAND EXECUTION above), rbash turns off any restrictions  in 
> >>the
> >>shell
> >>       spawned to execute the script.
> >>###
> >>
> >>So you just need to be able to write shell scripts to get around the
> >>restrictions?
> >>
> >>Hopefull sftp can be configured to do what you're wanting.
> >>
> >>apt-cache search for filezilla returns nothing, so I don't know if
> >>FileZilla can handle sftp. At least a few GUIs can.
> >>
> >>ciao,
> >>
> >>der.hans
> >>-- 
> >>#  https://www.LuftHans.com/    http://www.AZOTO.org/
> >>#  "Communications without intelligence is noise;
> >>#  Intelligence without communications is irrelevant."
> >>#  Gen. Alfred. M. Gray, USMC
> >>---------------------------------------------------
> >>PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> >>To subscribe, unsubscribe, or to change  you mail settings:
> >>http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> >>
> > 
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change  you mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> > 
> 
>