ANY user has the ability to ssh into an account that is meant to be
resrticted by RBAC. How can I stop this, while still allowing the
allowed users to use SSH? (we use SUN rays, and we can't get X
displays unless they use the SSH tunnels)
Serena
I'm going to guess the answers are perhaps OpenSSH, Solaris 8, and
Role-Based Access Control, but this is not obvious. There are "3.1"
versions of both OpenSSH and the ssh.com product. Assuming these are
correct...
SM> "SSH breaks RBAC"
No, SSH didn't "break" anything. You broke your own system by installing
a non-RBAC-aware program in a security-sensitive position and then
expecting it to follow RBAC rules. Perhaps you misunderstand how RBAC
works. It does not directly enforce restrictions on who can make system
calls, like e.g. the VMS mandatory access controls (different privilege
bits for "mount volume," "read all files," etc.). It establishes a system
for defining roles, "transactions" which those roles are authorized to
execute, and a method for users to assume those roles. Role authorization
must be checked by each program granting a right; that is, privileged
programs must be made RBAC-aware. OpenSSH is not. I don't know of an SSH
implementation that is. Perhaps Sun has plans to integrate RBAC into is
OpenSSH port at some point?
You might be able to get the effect you want by causing sshd to use an
RBAC-aware program at some critical point. For instance, if you set
"UseLogin yes" to have it use the host's login program, and login enforces
the RBAC restrictions, then maybe you'll get what you want. However, you
should check carefully. A particular sshd might use login only for
interactive logins; an SSH connection which did only executes a remote
command might bypass that, as might a connection which creates no session
channel by exists only to allow port forwarding.
--
Richard Silverman
sl...@shore.net
Am I being an idiot for not seeing this problem straight away? A
million and one papers, web guides, security recommendations etc
mention RBAC (solaris 8, as you spotted) and ssh (in my case 3.1.0) in
the same article, without commenting on the inherent incompatibility
between them.
The only solution I can see is to remove the password from the profile
account, which prevents access with ssh, then add users to the .shosts
file, to bypass the password check for these users.
Serena