rssh-discuss

restricting users with UID=0 does not work?

[Tomasz C. <ma...@wp...>]

I was trying to use rssh to restrict regular users - it works like
charm.

Then, I've tried to restrict users with UID=0 - unfortunately, chroot
doesn't seem to work in that case.

Consider the following users in /etc/passwd:

root:x:0:0:root:/root:/bin/bash
some@user:x:0:0::/mnt/storage/some@user:/usr/bin/rssh


I'm getting chroot for some@user when the UID is different than 0.
If the UID for some@user is set to 0, I'm no longer getting the
chroot and I'm able to browse the whole server.

Is it expected behaviour?



-- 
Tomasz Chmielewski
http://wpkg.org

Re: restricting users with UID=0 does not work?

[Tomasz C. <ma...@wp...>]

On Sun, 19 Jan 2014 07:35:05 -0800
Ben Walton <bdw...@gm...> wrote:

> > I'm getting chroot for some@user when the UID is different than 0.
> > If the UID for some@user is set to 0, I'm no longer getting the
> > chroot and I'm able to browse the whole server.
> 
> What do you expect to achieve by chrooting a uid=0 account? With
> uid=0, it is easy to step out of a chroot...chroot is not a security
> mechanism.

My usage scenario is as follows:

- user rsyncs (or uses sftp) data to a chrooted environment,

- as uid=0, the user is able to keep uids/gids exactly in sync with the
  origin server.


I'm aware that it's trivial to get out of chroot if you have a root
shell, but my impression was that rssh was the tool to prevent it.
Are there any known security issues with rssh which would allow a
chrooted user with uid=0 to bypass chroot? I assume the following:

- allowscp, allowsftp, allowrsync options enabled

- chroot environment read only, except the area where the users puts
  new data


-- 
Tomasz Chmielewski
http://wpkg.org

Re: restricting users with UID=0 does not work?

[Derek M. <co...@pi...>]

On Wed, Jan 15, 2014 at 11:20:02AM +0100, Tomasz Chmielewski wrote:
> I was trying to use rssh to restrict regular users - it works like
> charm.
> 
> Then, I've tried to restrict users with UID=0 - unfortunately, chroot
> doesn't seem to work in that case.
> 
> Consider the following users in /etc/passwd:
> 
> root:x:0:0:root:/root:/bin/bash
> some@user:x:0:0::/mnt/storage/some@user:/usr/bin/rssh

I would really need to re-read the source to guess what impact this
would have, but this is in general very bad practice, and by and
large, won't work the way you hope it will.  Reliably chrooting any
user whose UID is 0 CAN NOT WORK if they have full shell access.  This
is the primary purpose of this feature in RSSH; i.e. if your
restricted user is somehow able to bypass the protection provided by
RSSH and get a shell, the idea is that putting them in a chroot jail
limits the damage they can do.  However, if the user's UID is 0, they
can ALWAYS break out of any chroot jail so long as they can a) change
directory (anywhere) and b) find a way to call the chroot system call
(e.g. by running the chroot program, or by executing a custom-compiled
program they've uploaded within the jail).

I suspect that what's going on here is that getpwuid(), which will
simply read user entries (in your password file, NIS database, or
whatever authentication your system is configured to use) until it
finds the FIRST entry which matches that UID, is finding the entry for
root, and thus it is using whatever permissions root would have (or
possibly bypassing control entirely).

Having multiple users with the same UID, while possible, is basically
horribly broken, and can result in all kinds of unexpected behavior.
The security consequenses of this are hard to predict, and when the
UID in question is 0, you're just begging for serious problems.

In short, this is unsupported by RSSH, and behavior may vary based
upon exactly how your system is configured.  You should also generally
assume that any such user on your system can do anything, and most
especially expect that they can override whatever security
restrictions you THINK you've imposed upon them.

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D