[nycbug-talk] ChrootDirectory user w/OpenSSH 5.3 on OpenBSD 4.4

[Josh Rivel]

Jesse,

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>  
> wrote:
>> On Thu, Oct 15, 2009 at 11:22 AM, Josh Rivel <josh at rivels.org> wrote:
>>> Hi,
>>>
>>> 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  
>>> OpenBSD,
>>> 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,
>>> Josh
>>> _______________________________________________
>>> talk mailing list
>>> talk at lists.nycbug.org
>>> http://lists.nycbug.org/mailman/listinfo/talk
>>>
>>
>> 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,  
>> but
>> 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.
>>
>> -jesse
>>
>

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.

Josh