On Sun, Dec 15, 2002 at 09:36:20PM -0500, Greg A. Woods wrote:

> 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.

absolutely

> 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.

This is a very narrow view however; There are a number of reasons why
this may be wanted (although it has to be well implemented)... This includes
performance considerations obviously, and ability to delegate administration
tasks without allowing superuser privileges to anyone (not even to the
servers and applications running). It's not totally useless, unless of course
the "virtual users" application is broken. ACLs can be implemented even
if the kernel does not allow it, and in a portable manner.

Another useful approach is where FTP accounts are to be provided for a
number of users, it is obvious that shell access is unrequired. Then there
exists a conflict between administrators who want to provide their users
with standard FTP accounts but wish they never use their shell password
to login through this clear-text protocol...

Not to mention that openssh had a numerous number of security issues, it
remains to be proven that a good ssl-httpd configuration frontend for
all virtual activity is worse... (running as an unprivileged user but
not suffering from performance penalties).

To seriously affect the main system and software then implies exploiting
a buffer overflow vulnerability to then attempt to exploit another
system vulnerability to gain privileged access from that unprivileged user,
and then attempt to execute code... Instead of exploiting a single known
openssh problem to require a base system reinstall (unless a full virtual
server with it's performance loss drawbacks of course)...