[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [off-topic?] Chrooting ssh/telnet users?

Javier Fernández-Sanguino Peña <jfs@computer.org> writes:

> > Yes. Somehow, if you're going to run something, it needs to be in the
> > jail. Various alternatives to consider for various reasons : busybox,
> > rbash, sash.
> > What would be nice would be a union-mount, so you could graft a "real"
> > /bin on top of /home/foo/bin, and so on. I'm not sure that `mount
> > --bind' is the same thing?
> > 
> 	Umm... couldn't you have a restricted environment but with commands
> hard-linked in it to the proper ones and restricting thoroughly the hard
> links? (only rX, no w bits) 

Links created this way will not work 
a) cross-filesystem (and having a separate mountpoint for all chroot stuff
   is regarded as basically sensible)
b) to serve to separate permissions in one link from those in the other.

> The problem is how to do this automatically (and not checking dynamic
> dependencies one by one...)

...and the other rule is, don't do anything automatically that could lead
to shooting yourself in the head. You are expected to sit there & sweat it
out, `/bin/ls? Naaaah, don't need that' for each file in the jail.

> > FWIW I had to implement a chroot-jailled login for someone recently; if
> > anyone's interested, my attempts at the relevant C, nicked in part from
> > the appropriate manpages, are to be found below.
> > There is sufficient jiggery-pokery with arg{c,v} in here to allow
> >         ssh restricteduser@box "cat > foofile" < localfoofile
> > to transfer a file, but not to make scp work. (Don't ask me; don't take
> > this code as professional, bug-free, exploit-free or generally anything
> > other than rubbish, but it compiles, and it works.)
> > 
> 	Will take a look...

Bear in mind that what I did in order to set this up was a very simple
        zsh#  cp -av /^(mnt|proc) /mnt/chroot
        zsh#  chroot /mnt/chroot bash
        bash# dpkg --get-selections | awk '/install$/ {print $1}' > deb_list
        bash# vi deb_list
        bash# apt-get remove $(cat deb_list)
ie it's a complete copy of the running machine, offset by the magic of
chroot into another subdirectory (on a separate filesystem), with
significant numbers of packages removed, and various things like /bin/mount
It does *not* cater for vast hordes of users all having their own
environment, nor does it do the job properly by flinging files into the
chroot jail until they work - removing packages is not the same as building
up from minimum. But this was adequate for the user I had in mind, anyway.

The light of the world keeps shining,       |piglet@stirfried.vegetable.org.uk
Bright in the primal glow                   |http://spodzone.org.uk/

Reply to: