Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SSH breaks RBAC

1 view
Skip to first unread message

Serena

unread,
May 17, 2002, 3:22:10 AM5/17/02
to
I have RBAC implemented on my system, and also SSH 3.1 and it causing
a major security problem.

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

Richard E. Silverman

unread,
May 17, 2002, 5:01:36 PM5/17/02
to

First of all -- details? What SSH? What OS? What is "RBAC?"

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

Serena

unread,
May 21, 2002, 12:54:29 PM5/21/02
to
sl...@shore.net (Richard E. Silverman) wrote in message news:<m1lg00q...@syrinx.oankali.net>...

>
> 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.
>
I understood, i was simply under the impression that the psfh itself
forced the user id check (via PAM_RUSER). I can see now that ssh can
bypass the default shell when a password is present.

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

0 new messages