Today I modified OpenSSH so that it allows me to configure in a generic
way, restrictions on what server functions can be used by system users
after they authenticate. The partial implementation of my plans only
works for SSH2, but allows me to write entries like the following in
sshd_config:
ChannelReqDeny shell g restricted
ChannelReqDeny exec g restricted
ChannelReqDeny x11-req u *
... to deny access to those channel requests for group 'restricted'.
Using my modified sftp-server, I can also write this:
Subsystem sftp /path/to/sftp-server
SetIf g restricted Subsystem sftp /path/to/sftp-server --chroot
... and anyone in the same group is jailed to the cwd, i.e. their home
directory.
The above works fine, but I want to expand it further. Bearing in mind
that 2 days ago I'd never before looked at the SSH code or the RFCs, I
thought I'd get some feedback from people on this list.
What do you think? Are these features useful for other people? Am I
taking the right approach?
It's a really simple implementation, using single-linked lists in the
Options struct which are scanned at the right places. The SetIf list is
checked in do_authenticated() and the command processed as a normal
configuration line. Due to the fork() model, I'm under the impression
that the latter option's changes can't persist beyond the current
session.
I considered all sorts of other more flexible approaches, but I don't
have a lot of time to spend on this. IMHO this way allows expansion for
features that immediately come to mind, such as matching on IP, allow
lists and then choosing deny/allow order.
Given a few of hours of free time in the next week, I'd like to decide
what to do about connections using other versions of the protocol (which
currently bypass these restrictions) and further develop the approach to
cover the other 2 major messages detailed below.
* SSH_MSG_GLOBAL_REQUEST {"tcpip-forward",
"cancel-tcpip-forward",
"direct-tcpip"}
returning SSH_MSG_REQUEST_FAILURE
* SSH_MSG_CHANNEL_OPEN {"session", "x11", etc...}
returning SSH_OPEN_ADMINISTRATIVELY_PROHIBITED
I'm also going to resolve an issue where sftp-server can't send the
client the real user/group after chroot().
Eventually, I could see this code becoming a base for more user-friendly
options based on functionality rather than protocol messages. e.g. the
option 'X11Forwarding no' could add to the ChannelDeny list rather than
cluttering the code with the existing extra variables; 'AllowExec no'
could do the same as denying 'exec' and 'shell'.
I'll have to grab the latest version of OpenSSH (this was done on the
version distributed with Ubuntu stable - 4.3p2) and sync the changes up
before posting a patch.
Jon.