[SOLVED] Correct way to set PATH for rksh?

Turbocapitalist · 01-20-2017, 10:58 AM

In OpenBSD, what is the correct way to set $PATH for logins for accounts that use rksh? I don't want something that can be overrriden by the the account.

If I set the account's shell to /bin/rksh using usermod then the following sshd configuration gives the error "rksh: PATH: restricted" when connecting.

Code:

Match Group games
        ForceCommand PATH=/usr/games:/usr/rbin /bin/rksh

If I remove the PATH component, it still gives the error "rksh: /bin/rksh: restricted"

Code:

        ForceCommand /bin/rksh

If I shorten it to the following, then PATH is set to the system default and not using the account's .profile

Code:

        ForceCommand rksh

The first option above does what I want if I set the account shell to normal /bin/ksh but then any shell escapes pop out to ksh and not rksh.

What is the trick to setting $PATH for accounts that are using /bin/ksh for a shell?

jggimi · 01-20-2017, 02:31 PM

rksh(1) will only read and set the $PATH variable from $HOME/.profile.

If you really have a clear use-case for rskh(), add /bin/rksh to the shells(5) database and assign it as the untrusted user's login shell. I believe that sshd_config(5) ForceCommand is the wrong hammer for this particular nail.

---

Disclaimer: I've never used rksh() in production. I don't give untrusted users shells. The closest they get is chrooted, sftp-only access, via ForceCommand internal-sftp:

Code:

Subsystem sftp internal-sftp
Match Group sftpusers
        ChrootDirectory %h
        ForceCommand internal-sftp

jggimi · 01-20-2017, 02:49 PM

I just looked, and /bin/rksh was REMOVED from the shells database in 1997. The CVS commit log states:

Code:

CVSROOT:        /cvs
Module name:    src
Changes by:     deraadt@cvs.openbsd.org 1997/05/28 15:42:21

Modified files:
        etc            : shells 

Log message:
rksh is wrong, here

It appears to me that there is no established best practice for using rksh().

Turbocapitalist · 01-21-2017, 12:53 AM

Quote:

Originally Posted by jggimi

rksh(1) will only read and set the $PATH variable from $HOME/.profile.

Thanks. That would work for me but I'm not seeing that either in the manual page for rksh(1) or in practice.

Code:

$ echo $0; echo $PATH
rksh
/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin

I should be seeing a different $PATH there, not the default if .profile were being used.

Quote:

Originally Posted by jggimi

If you really have a clear use-case for rskh(), add /bin/rksh to the shells(5) database and assign it as the untrusted user's login shell. I believe that sshd_config(5) ForceCommand is the wrong hammer for this particular nail.

This is one case where I want to grant limited shell access so that a handful of programs can be run, but nothing else. OpenBSD does not have jails (that I know of) and SFTP is not enough.

The reason for also needing ForceCommand is that even with the user shell set to rksh(1) for normal login, it is still possible to run arbitrary commands via the SSH client. That includes running full shells or any arbitrary commands. For example, the following circumvents the preset rksh(1) that the account might have had in /etc/passwds

Code:

ssh user@host.example.com '/bin/ksh'

Thus apparent need to set rksh(1) in two places.

jggimi · 01-21-2017, 08:13 AM

Quote:

Originally Posted by Turbocapitalist

Thanks. That would work for me but I'm not seeing that either in the manual page for rksh(1) or in practice.

Code:

$ echo $0; echo $PATH
rksh
/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin

I should be seeing a different $PATH there, not the default if .profile were being used.

I tested this before posting above. It was a local system test, without ssh. I've recreated it:

Code:

# echo /bin/rksh >> /etc/shells
# adduser 
.
.
.
# mkdir /home/test-user/bin
# echo PATH=/home/test-user/bin > /home/test-user/.profile
# echo export PATH HOME BIN    >> /home/test-user/.profile
# login test-user
Password:
$ ls
rksh: ls: not found
$ echo $PATH
/home/test-user/bin
$ /bin/ls
rksh: /bin/ls: restricted
$

I've extended the test to include ssh. Please ignore the custom kernel, it isn't germane to the test.

Code:

$ ssh test-user@localhost
test-user@localhost's password: 
OpenBSD 6.0-current (HZ1000) #16: Fri Jan 20 21:52:18 EST 2017

$ ls
rksh: ls: not found
$ exit
Connection to localhost closed.
$ ssh test-user@localhost /bin/ksh
test-user@localhost's password: 
rksh: /bin/ksh: restricted
$ ssh test-user@localhost '/bin/ksh'
test-user@localhost's password: 
rksh: /bin/ksh: restricted

So while the ssh(1) man page says that a command "will be run instead of the login shell," it appears the user's shell is deployed to execute the command.

What appears clear to me from mucking about with rskh() for a few minutes is there are many ways it could be defeated. Such as having a $PATH which includes access to any other shell. That, I think, is why you're looking at ForceCommand. Instead, look carefully at that $PATH.

jggimi · 01-21-2017, 08:30 AM

For clarity regarding rskh and the $PATH:

The rksh(1) and ksh(1) man page (same page) states that when restricted, the shell will not execute anything with an absolute or relative path. This is why /bin/sh fails even if I have /bin in my $PATH. I can't use /bin/sh as that is absolute, nor could I use ../../bin/sh, because that is relative. But if I have /bin in the $PATH, just issuing "sh" is enough to get an unrestricted shell.

That section of the man page also describes the initial setting of $PATH and other environment variables.

Turbocapitalist · 01-21-2017, 08:41 AM

Quote:

Originally Posted by jggimi

Instead, look carefully at that $PATH.

Right. I have set $PATH in .profile long ago. However, it has only been used by the system when I use su(1) with the -l option to log in or log in from the console, not via ssh(1):

Code:

$ echo $0
-rksh
$ echo $PATH
/usr/games:/usr/local/rbin
$ cat .profile
PATH=/usr/games:/usr/local/rbin
export PATH HOME TERM

When logging in with ssh(1) I get the full default $PATH if I have the ForceCommand in place:

Code:

ForceCommand rksh

The $PATH turns out like this then with ForceCommand

Code:

$ echo $0
rksh
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin

If I do not have the ForceCommand in place, then it is possible to pass a full shell as a log in argument and have it accessible:

Code:

ssh -t user@host.example.com ksh

So currently I can choose Either reading $PATH from the account's .profile XOR preventing arbitrary commands getting passed as options with ssh(1). Neither is functional because the latter allows full shell directly and the former allows full shell via the unrestricted $PATH contents.

Frustrated.

jggimi · 01-21-2017, 09:05 AM

If any shell other than /bin/rskh is available to the restricted user, the user can trampoline themselves right out of the restricted shell.

The key problem: You have /bin in your $PATH. The "restricted" user has access to sh(1), ksh(1), and csh(1).

To eliminate ready access to those shells, you must remove /bin from the $PATH. That also eliminates access to many other, useful utilities, too. So any needed utilites, such as ls(1), would need to linked into the restricted user's $PATH. I just tested this, and a symbolic link to /bin/ls worked fine.

You also have /usr/local/bin in your $PATH. Any third party shell that is installed -- and there are 13 available -- would also be readily available to your restricted user.

----

While there is no best practice for rksh() in OpenBSD, if I found myself forced into using it, I would create a private $PATH with none of the standard directories included. I would link in only those tools that were absolutely needed to support the particular use-case. And if possible, I would further isolate the users to their own platform, as I would assume compromise is possible even with all of that.

Turbocapitalist · 01-21-2017, 09:14 AM

Quote:

Originally Posted by jggimi

To eliminate ready access to those shells, you must remove /bin from the $PATH. That also eliminates access to many other, useful utilities, too. So any needed utilites, such as ls(1), would need to linked into the restricted user's $PATH. I just tested this, and a symbolic link to /bin/ls worked fine.

You also have /usr/local/bin in your $PATH. Any third party shell that is installed -- and there are 13 available -- would also be readily available to your restricted user.

Yes. You now understand the question.

I have set $PATH in .profile, see above for details. It is being ignored when I connect in with ssh(1) while sshd(8) is configured to use a ForceCommand of any kind to rksh(1).

Maybe this is affected by architecture if it is working for you?

Code:

# dmesg | head 
OpenBSD 6.0-current (GENERIC) #28: Tue Jan 17 22:50:53 MST 2017
    build@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 536870912 (512MB)
avail mem = 517787648 (493MB)
mainbus0 at root: TI AM335x BeagleBone Black
cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache
omap0 at mainbus0
prcm0 at omap0 rev 0.2

jggimi · 01-21-2017, 09:15 AM

Looking again, are you sure your user was set to use /bin/rksh as the login shell while it had a restricted $PATH? When I did that, above, I could not pass a string with another shell in it.

Turbocapitalist · 01-21-2017, 09:21 AM

Quote:

Originally Posted by jggimi

Looking again, are you sure your user was set to use /bin/rksh as the login shell while it had a restricted $PATH?

Yes. I used usermod(8) to set the shell for that account to /bin/rksh It works fine from the console and with su(1), the $PATH gets set as expected.

Yet with that, I am able to bypass rksh(1) with ssh(1)

Code:

$ ssh -t user@host.example.com 'ksh'
$ echo $0
ksh

jggimi · 01-21-2017, 09:23 AM

AH, I *was* able to reproduce the circumvention, using:

Code:

$ ssh -t test-user@localhost sh

Turbocapitalist · 01-21-2017, 09:27 AM

Quote:

Originally Posted by jggimi

AH, I *was* able to reproduce the circumvention, using:

Code:

$ ssh -t test-user@localhost sh

Great. But that's the expected behavior from plain vanilla sshd(8).

If you then add a Match clause for your test-user to force a command, specifically rksh(1), you will run into the $PATH problems described above.

jggimi · 01-21-2017, 09:35 AM

Now that I've been able to reproduce this -- and, now that I better understand it, too

-- I'm looking at ForceCommand. The man page says that it executes the login shell with -c.

Let me reproduce the ForceCommand problem here, and then I'll see if I can figure out what the root cause is.

jggimi · 01-21-2017, 09:47 AM

Oh, kay. I have what I think is a possible solution. Set the ForceCommand string to "/bin/rksh -l" which will cause the shell to execute $HOME/.profile upon startup.