Subject: Re: Implementing jail
To: Matthew Mondor <mmondor@gobot.ca>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 12/15/2002 21:36:20
[ On Sunday, December 15, 2002 at 20:20:27 (-0500), Matthew Mondor wrote: ]
> Subject: Re: Implementing jail
>
> I agree, there is even more and more software which can work with virtual
> users now, (unfortunately I did not see an sshd implementation of this
> however).
An sshd that authenticated virtual users would be, by definition, an
oxymoron; an impossibility.
You cannot have virtual users and grant them access with SSH. It's
simply not logically possible and would completely contravene the Unix
security model.
The whole purpose of SSH authentication is to authenticate _real_ users.
You can only do that by translating the real user's actions in the
system into those of a unique system user identity. This is a very
basic requirement of any "trusted" computing system.
I.e. the only way to securely allow _real_ users access to a Unix-like
system is to create full and proper and unique Unix accounts for each
person and to use a secure authentication mechanism to ensure that only
one real person can gain access to any given system account.
This whole idea of virtual users is completely bogus, impossible, and
even delusional in any unix-like system. Unix-like systems have one
privileged user (the superuser), and optionally multiple other users
who's privileges are relative to the files they own and have various
forms of access to. The moment you have a user account which can be
accessed by multiple users without some external form of authentication
and activity audit trail you end up with no secure way to tell what real
person did what.
(note that things like Cyrus IMAP are not really creating true virtual
users because no true permanent system objects are ever owned by any
user -- all they do is push the ownership handoff one step further from
the mailbox spool file to the IMAP connection, and thus the
authentication and authorisation is really happening at the network
level, not at the system level)
(and this isn't even with C-2 (orange book) security in mind -- just the
plain old original unix security model. something like the C-2 level of
security or better absolutely requires unique system accounts for every
real person)
Besides, it's a huge waste of time an effort, never mind the increased
risks, to even think of trying to re-implement all the system security
mechanisms to authenticate, authorize, and audit user activities outside
the existing kernel mechanisms (i.e. at user-level within the bounds of
one lone system identity). If you really want "virtual" users then the
best way to do that is to create one or more full virtual systems and
run them in true hardware emulation on your real system. That way
everything just works -- there's nothing to re-invent (and break) and
nothing that can allow different groups of virtual users on different
virtual systems to directly interfere with each other (and if one or
more virtual systems runs out of resources you can either move it to a
more capable emulation system, or even to a real hardware system).
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>