Re: 200alpha15 (security guards)

["Neil W. Van Dyke" <nwv@neilvandyke.org>]

These security guards sound like they may be useful.

A few quick comments that come to mind (perhaps naive, and certainly
incomplete, since I know only a little about security):

1. Complementing the ability to restrict access to file and network
   resources would be the ability to limit access to memory and CPU
   resources.  This would eliminate some obvious denial-of-service
   attacks against the Scheme and/or OS host environments.

   This limiting might be implemented by running untrusted code in a
   thread that has per-thread memory and CPU resource limits.  The
   limits would be set in such a way that untrusted code could not
   increase the limits of its threads.

   If the untrusted code running in the limited thread had the ability
   to create new threads, there should probably be an upper limit on the
   number of new threads that can be thus created.  Also, creation of
   subthreads should not substantially increase the total amount of
   memory&CPU resources available to the untrusted code.

2. It seems that, for a lot of situations in which we'd have untrusted
   code running in a thread, there would be other code in the same
   "mzscheme"/"mred"/etc. process from which we'd want to restrict
   references.

   For one example, if a student is using DrScheme's Help Desk to browse
   interactive illustrations on arbitrary Web pages (HTML pages with
   MzScheme code embeded for client-side execution), then the untrusted
   code should not be able to access arbitrary DrScheme GUI objects,
   since that would likely permit the untrusted code to execute arbitrary
   code (with or without tricking the human user into assisting it).

   For another example, a Scheme environment executing two threads of
   untrusted code from different sources -- say, a server hosting two
   hunks of mobile agent code representing two different parties in a
   financial transaction or carrying privacy-sensitive information --
   should restrict the two threads of untrusted code from examining each
   other.

3. I haven't looked into how the the installable ".plt" add-on
   collection packages work, but a few simple safeguards there would be
   helpful.

   For new students, it might be good if the Help Desk did not make it
   *too* easy for new students to install ".plt" files from *arbitrary*
   Web pages.

   For more experienced PLT users, it would be good if ".plt" files from
   untrusted sources could write only to a newly-created collection
   directory (i.e., "<PersonalPLTDir>/collects/<NonexistentDir>/") and
   that no unrestricted code be executed by the installation process
   without offering the user the opportunity to examine the files that
   have just been installed.

   The latter may mean allowing examination of the files *before* ".zo"
   compilation occurs.  This would both relieve us from some of the
   responsibility of restricting the compilation process, and also
   defeat a class of evidence-hiding trick wherein the `source' files
   that go into the compiler are not the 'source' files the user sees
   after the compilation occurs.

None of these are showstopper issues for most uses of PLT, of course.

Best regards,

Neil

-- 
                                                        Neil W. Van Dyke
                                             http://www.neilvandyke.org/