🚀 go-pugleaf

sethb@fid.morgan.com (Seth Breidbart) writes:

>What I need is the ability to run a subprocess as a slave; whenever it
>tries to do any kind of system call, the call is handed to me (the
>master process) instead.  That way, I can allow only "safe" actions; I
>can also pretend to have done "unsafe" actions so the subprocess will
>run without causing trouble.

        A good idea.  It's suprising that UNIX doesn't have something
like this, as a debugging tool.  It wasn't there in original UNIX
because the system had to work without enough memory for more than one
active process at a time.  But that's not an issue today.

        Of course, there's now a risk that this mechanism could be used
to spoof set-UID programs.  So that issue has to be dealt with.

        The ability to restrict a process to a strict subset of its
parent's privileges is promising.  The ability to run a subprocess which
could open no files and sockets other than those inheirited from the parent 
would be a good first step in running software of unknown origin.

        Now, if attempts to open files/sockets notify the parent, we've
got something.  We could have a shell which forks off child processes
with the capability to open any file named on the command line, and nothing
else.  Anything else pops up an alert box, with something like 
"'ghostscript' wants to open '/etc/passwd' for writing?  Permit this?"
Some programs (those considered not to contain Trojan horses) might be
launched with stronger privileges.  But you could run software of
dubious origin with some hope of containing its effects.  Some way to do
that is needed badly if programmable objects are to be passed around as
documents.   Or we're going to have a whole new class of viruses and worms.

        You really can't add on security as an afterthought.  Many
people have tried and failed.  But I suppose the UNIX community has to
keep trying until something better comes along.

					John Nagle