[nycbug-talk] ChrootDirectory user w/OpenSSH 5.3 on OpenBSD 4.4
josh at rivels.org
Fri Oct 16 20:58:12 EDT 2009
On Oct 16, 2009, at 3:55 PM, Jesse Callaway wrote:
> On Fri, Oct 16, 2009 at 1:59 PM, Jesse Callaway <bonsaime at gmail.com>
>> On Thu, Oct 15, 2009 at 11:22 AM, Josh Rivel <josh at rivels.org> wrote:
>>> So I'm trying to setup a user on my OpenBSD 4.4 box (OpenSSH 5.3)
>>> using the ChrootDirectory option in sshd_config. I know that for a
>>> scp/sftp only account it's trivial and you don't need to do anything
>>> other than what's in the manpage for sshd_config. However, for ssh
>>> access there's more required. I found quite a few guides on how
>>> to do
>>> this with Linux, but I'm wondering if anyone has done it with
>>> or can provide me with a suggestion on how to give someone a shell
>>> account on my box, but not let them have access to any files outside
>>> of /home/username. If it were a FreeBSD box or OpenSolaris I could
>>> just setup a jail for them, but it's not. I came across jailkit -
>>> http://olivier.sessink.nl/jailkit/ - has anyone used that w/OpenBSD?
>>> It looks like it might do what I need it to.
>>> Thanks in advance,
>>> talk mailing list
>>> talk at lists.nycbug.org
>> I've only done this in linux as well. But either way, you'll need to
>> run your shell entirely in the chroot. I'm guessing you know this,
>> don't hit me if you do. Usually your shell program is dynamically
>> linked to libraries in order to do anything interesting. These
>> libraries will likely lie outside of the chroot, in your system
>> library directories. So one thing you'll need to do is either a) list
>> the libraries using the 'ldd' tool and make them accessible in the
>> chroot path. Or b) find yourself a statically linked shell.
>> You will likely need to have some sort of /etc/passwd file in there
>> unless you use directory services. I usually just have a couple lines
>> for any users in that chroot.
>> Do this for all the commands you want to run in the chroot
>> environment. There is a great deal of overlap in these libraries, I
>> guess that's the point, right ; ) Point being, once you satisfy the
>> shell things like cp, ls, etc should already be covered.
>> I'm not sure what login classes are, and Michaels' mention of them
>> makes me want to get educated on them as well. Whatever the case, if
>> you do use the chroot option you'll need to go through the usual
>> rigamorole as described above.
Yeah, I was trying to avoid making copies of various libraries, etc.
into a chroot jail. Also I have all my filesystems mounted nodev/
nosuid, so that's a small issue as well.
(Yes I could remount them)
> Eh... now you're making me install Open. Login classes are defined in
> /etc/login.conf. The login class may also have MAC policies tied to
> it. I didn't see anywhere how login classes alone could help solve the
> problem of restriction access to certain parts of the filesystem,
> except in the case of ftp.
> So I'm guessing that their use and subsequent definitions of a MAC
> scheme for the restricted users would get you what you want. You've
> probably read up much more on this than I have by now.
I did some reading up on login classes/login.conf as well, seems a bit
overkill. A friend of mine (who's also on this list) - Thanks Rick! -
suggested making the users shell /bin/rksh, setting their profile to
have PATH=$HOME/bin, making .profile owned by root, and then just
putting whatever binaries they need into ~user/bin - I've been testing
it out and it seems to work, no need for any jails, copying libraries
around, etc. If I don't want them to have access to a command, I just
don't put it into ~user/bin, and they can't cd out of it.
More information about the talk