Thread: restricting users with UID=0 does not work?
Brought to you by:
xystrus
From: Tomasz C. <ma...@wp...> - 2014-01-15 10:20:12
|
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 |
From: Tomasz C. <ma...@wp...> - 2014-01-19 21:44:41
|
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 |
From: Derek M. <co...@pi...> - 2014-01-20 00:45:10
|
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 |