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

[Andres Salomon]

argh, this sounds like the sort of thing that would've been useful
when i set up rsync on our company backup machine (as opposed to writing
a small shell that chrooted and ran rsync).

it doesn't appear to be in debian unstable; apt-cache shows no third
party module for it, and it's most definitely not included in stock pam.
according to the rpm changelog, redhat added it on 10/02/00, somewhere
 before 0.73 was merged.  the readme in the modules/chroot directory
identifies the source as ftp://ferret.lmh.ox.ac.uk/users/weejock/pam_chroot/.

i would love to see it packaged; i put redhat's source tarball at
http://etc.mp3revolution.net/pam-redhat-0.74-22.tar.gz

On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote:
> 
> On 26/10/01, Javier Fern?ndez-Sanguino Pe?a wrote:
> > The problem is, how can an admin restrict remote access from a given user
> > (through telnet and/or sshd) in order to limit his "moves" inside the
> > operating system.
> [...]
> > AFAIK, pam only allows to limit some user accesses (cores, memory
> > limits..) not users "movement" in the OS
> 
> That's a wrong assumption. At least RedHat contains a pam_chroot.so
> module which can be used in connection with the latest ssh to limit a
> user into a chroot. I'm just wondering if that module is packaged
> already for debian or not.
> 
> Christian
> -- 
>Debian Developer (http://www.debian.org)
> 1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853



-- 
"I think a lot of the basis of the open source movement comes from
  procrastinating students..."
-- Andrew Tridgell 

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

[Tim Haynes]

Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> 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? Nh, 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 [EMAIL PROTECTED] "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
removed.
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.

~Tim
-- 
The light of the world keeps shining,   |[EMAIL PROTECTED]
Bright in the primal glow   |http://spodzone.org.uk/

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

[Ethan Benson]

On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote:
> Rishi L Khan <[EMAIL PROTECTED]> writes:
> 
> > I think the only way to accomplish a chroot IS to include all the files
> > in the jail that the user needs.
> [snip]
> 
> 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?

mount --bind would work, but you must ask yourself why you bother with
chroot if your just going to bind mount the entire filesystem into the
chroot jail anyway (which is just about what you must do for things to
work properly) when you bind mount /bin and /usr/bin you get all the
suids in those directories in the chroot, you also need /etc for the
global config files many programs use.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpdzIHVkJvzK.pgp
Description: PGP signature

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

[Javier Fernández-Sanguino Peña]

I would be interested only in the chroot patch. Is there any
reason you have not contributed it to openssh? Do you want me to do it?

Best regards

Javi

On Fri, Oct 26, 2001 at 05:24:13PM +0300, Ivan Dimitrov wrote:
> recently i've worked on a small patch for openssh that chroots a user when
> he logs in. it uses mysql for password auth. it is not posted anyware but
> if you want it, send me a personal mail.
> 
> 
>  Ivan Dimitrov
>   System Administrator
> Bastun Networks
> 

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

[Sunny Dubey]

On Friday 26 October 2001 09:14 am, Javier Fernández-Sanguino Peña wrote:
> I have been asked for this and I was trying to figure out how to do it
> (would document it later on in the Securing-Debian-Manual). So please,
> excuse me if you feel this is off-topic.
>
> The problem is, how can an admin restrict remote access from a given user
> (through telnet and/or sshd) in order to limit his "moves" inside the
> operating system.
>

no idea if this will help

but you could change their shells from bash to rbash (or bash -r)
its pretty crappy however

Sunny Dubey

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

[Javier Fernández-Sanguino Peña]

On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote:
> Rishi L Khan <[EMAIL PROTECTED]> writes:
> 
> > I think the only way to accomplish a chroot IS to include all the files
> > in the jail that the user needs.
> [snip]
> 
> 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) The problem is how to do this
automatically (and not checking dynamic dependencies one by one...)

> 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...

Regards

Javi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Javier Fernández-Sanguino Peña]

On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote:
> That's a wrong assumption. At least RedHat contains a pam_chroot.so
> module which can be used in connection with the latest ssh to limit a
> user into a chroot. I'm just wondering if that module is packaged
> already for debian or not.
> 
That seems like an interesting solution (another reader suggested
it to me off the list). I will take a look and package it into Debian if
it seems interesting.

Javi

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

[Andres Salomon]

argh, this sounds like the sort of thing that would've been useful
when i set up rsync on our company backup machine (as opposed to writing
a small shell that chrooted and ran rsync).

it doesn't appear to be in debian unstable; apt-cache shows no third
party module for it, and it's most definitely not included in stock pam.
according to the rpm changelog, redhat added it on 10/02/00, somewhere
 before 0.73 was merged.  the readme in the modules/chroot directory
identifies the source as ftp://ferret.lmh.ox.ac.uk/users/weejock/pam_chroot/.

i would love to see it packaged; i put redhat's source tarball at
http://etc.mp3revolution.net/pam-redhat-0.74-22.tar.gz

On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote:
> 
> On 26/10/01, Javier Fern?ndez-Sanguino Pe?a wrote:
> > The problem is, how can an admin restrict remote access from a given user
> > (through telnet and/or sshd) in order to limit his "moves" inside the
> > operating system.
> [...]
> > AFAIK, pam only allows to limit some user accesses (cores, memory
> > limits..) not users "movement" in the OS
> 
> That's a wrong assumption. At least RedHat contains a pam_chroot.so
> module which can be used in connection with the latest ssh to limit a
> user into a chroot. I'm just wondering if that module is packaged
> already for debian or not.
> 
> Christian
> -- 
>Debian Developer (http://www.debian.org)
> 1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853



-- 
"I think a lot of the basis of the open source movement comes from
  procrastinating students..."
-- Andrew Tridgell 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Tim Haynes]

Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> 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? Nh, 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
removed.
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.

~Tim
-- 
The light of the world keeps shining,   |[EMAIL PROTECTED]
Bright in the primal glow   |http://spodzone.org.uk/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Ethan Benson]

On Fri, Oct 26, 2001 at 04:35:14PM +0100, Tim Haynes wrote:
> Rishi L Khan <[EMAIL PROTECTED]> writes:
> 
> > I think the only way to accomplish a chroot IS to include all the files
> > in the jail that the user needs.
> [snip]
> 
> 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?

mount --bind would work, but you must ask yourself why you bother with
chroot if your just going to bind mount the entire filesystem into the
chroot jail anyway (which is just about what you must do for things to
work properly) when you bind mount /bin and /usr/bin you get all the
suids in those directories in the chroot, you also need /etc for the
global config files many programs use.  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

 PGP signature

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

[Javier Fernández-Sanguino Peña]

I would be interested only in the chroot patch. Is there any
reason you have not contributed it to openssh? Do you want me to do it?

Best regards

Javi

On Fri, Oct 26, 2001 at 05:24:13PM +0300, Ivan Dimitrov wrote:
> recently i've worked on a small patch for openssh that chroots a user when
> he logs in. it uses mysql for password auth. it is not posted anyware but
> if you want it, send me a personal mail.
> 
> 
>  Ivan Dimitrov
>   System Administrator
> Bastun Networks
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Sunny Dubey]

On Friday 26 October 2001 09:14 am, Javier Fernández-Sanguino Peña wrote:
> I have been asked for this and I was trying to figure out how to do it
> (would document it later on in the Securing-Debian-Manual). So please,
> excuse me if you feel this is off-topic.
>
> The problem is, how can an admin restrict remote access from a given user
> (through telnet and/or sshd) in order to limit his "moves" inside the
> operating system.
>

no idea if this will help

but you could change their shells from bash to rbash (or bash -r)
its pretty crappy however

Sunny Dubey


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Javier Fernández-Sanguino Peña]

On Fri, Oct 26, 2001 at 05:25:28PM +0200, Christian Kurz wrote:
> That's a wrong assumption. At least RedHat contains a pam_chroot.so
> module which can be used in connection with the latest ssh to limit a
> user into a chroot. I'm just wondering if that module is packaged
> already for debian or not.
> 
That seems like an interesting solution (another reader suggested
it to me off the list). I will take a look and package it into Debian if
it seems interesting.

Javi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]