Security - suggested hack using chroot

[Alan S. Watt]

A lot of discussion on this.  I've thought about using the "chroot" call
to dump people into a separate environment where they can't do any
damage except to each other.  If you plan to do this, you should be
aware that a separate filesystem does NOT give you a separate "virtual
machine".  Several obvious differences:

  1)	All processes on the same CPU vie for the same fixed pool of
	CPU time.  Nothing stops people on your "protected" environment
	from firing up lots of CPU-eating processes.

  2)	Lots of things in UNIX are global to the kernel, and not separate
	for each file system.  One example is process ID's.  If you had
	a super-user on the "protected" system, and a "ps" command which
	could look up the right system symbol table and peek into kernel
	memory, said super-user could kill processes owned by users on
	the outside environment.  For this reason, you can't "recycle"
	user ID's and have the same UID used both by a normal user and
	one in the protected environment; the "protected" user could
	write a program which executed the system call:

		kill(-1,9);	/* If that's the right order */
	
	which would kill all processes for which he had permission.

The idea still has a lot of merit, as it does accomplish one major goal,
which is to make data on the main part of the system inaccessable to
users on the protected environment.

How about this for a starting point:

  1)	Have a login "guests" or something, with user-id 0, running a
	special program which does a "chroot" to the protected area
	(let's just say "/subenviron"), and does the following other
	things:

	  a)	Sets "nice" to 2 or thereabouts.

	  b)	If running VMUNIX, uses the "vmlimit" command to set
		limits on CPU time, dataspace, etc. (this may be pointless;
		"csh" will allow them to set it back easily enough).

	  c)	Execs "/bin/login" (which is really "/subenviron/bin/login").

  2)	This second login program would read "/subenviron/etc/passwd"
	for the list of valid login ID's.  System administrators would
	take care that all UID's and GID's in this file were unique to
	this sub-environment, and did not occur in the "main" system,
	or in other sub-environments (say by adding N*1000 to them,
	where <N> is the number of the sub-environment).  In no case should
	an entry for the super-user appear here.

  3)	The sub-environment would have all device entries for disks, tapes,
	etc., removed.

  4)	There are still some other holes, for example Tty devices will have
	to appear in this restricted environment, and users could do the
	usual "stty raw noecho >/dev/tty$random_name", and screw up some
	poor person in the main environment on that tty node.  This could
	be eliminated by making the program which issues the "chroot" call
	instead set up a connection to a pty master node, where the slave
	node exists in the sub-environment, where there is already an
	"init" running, having done a "chroot".  This adds considerably
	to the overhead however.

Anything I've missed?  It seems much simpler to just define another "VM"
user, and run another copy of "UTS" in that virtual machine partition.
Guaranteed to work and give you absolute separation of the two environments.
Further, you can use "VM" tools to assign various priority restrictions
to one partition.

	- Alan S. Watt