Configurable restrictions

[Jonathan Miles]

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.