Re: [racket-dev] sandbox and file-/directory-existence tests

2013-08-19 Thread Matthew Flatt
Thanks! Instead of changing 'exists permissions, I think I found the
right approach to moving the computation so that it doesn't interact
with the sandboxes.

At Mon, 19 Aug 2013 16:49:28 -0400, Eli Barzilay wrote:
> A few minutes ago, Sam Tobin-Hochstadt wrote:
> > On Mon, Aug 19, 2013 at 4:34 PM, Matthew Flatt  wrote:
> > >
> > > Is there a situation where allowing an arbitrary file- or
> > > directory-existence test would be bad?
> > 
> > This all depends on how paranoid we want to be.  There are certainly
> > situations when this will be bad -- it lets you determine who else
> > has an account on a computer, for example.  But there are contexts
> > where having GC be observable is a security hole as well, so we have
> > to pick a spot on the continuum.
> 
> Getting some hacker-useful information from an observable GC time is
> much harder than doing so from FS existence tests.  Two quick
> examples:
> 
>   * On a unix machine, check if there's a /tmp/shadow file -- if there
> isn't then you have a machine that is a potential gold mine for
> hackers.
> 
>   * On a windows machine you can use some network drive or a drive of
> some random device for a kind of a local DOS attack.
> 
> (There's probably a lot of similar things that are much more
> sophisticated; probe attacks in general are very common now.)
> 
> -- 
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] sandbox and file-/directory-existence tests

2013-08-19 Thread Eli Barzilay
A few minutes ago, Sam Tobin-Hochstadt wrote:
> On Mon, Aug 19, 2013 at 4:34 PM, Matthew Flatt  wrote:
> >
> > Is there a situation where allowing an arbitrary file- or
> > directory-existence test would be bad?
> 
> This all depends on how paranoid we want to be.  There are certainly
> situations when this will be bad -- it lets you determine who else
> has an account on a computer, for example.  But there are contexts
> where having GC be observable is a security hole as well, so we have
> to pick a spot on the continuum.

Getting some hacker-useful information from an observable GC time is
much harder than doing so from FS existence tests.  Two quick
examples:

  * On a unix machine, check if there's a /tmp/shadow file -- if there
isn't then you have a machine that is a potential gold mine for
hackers.

  * On a windows machine you can use some network drive or a drive of
some random device for a kind of a local DOS attack.

(There's probably a lot of similar things that are much more
sophisticated; probe attacks in general are very common now.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] sandbox and file-/directory-existence tests

2013-08-19 Thread Sam Tobin-Hochstadt
On Mon, Aug 19, 2013 at 4:34 PM, Matthew Flatt  wrote:
>
> Is there a situation where allowing an arbitrary file- or
> directory-existence test would be bad?

This all depends on how paranoid we want to be.  There are certainly
situations when this will be bad -- it lets you determine who else has
an account on a computer, for example.  But there are contexts where
having GC be observable is a security hole as well, so we have to pick
a spot on the continuum.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] sandbox and file-/directory-existence tests

2013-08-19 Thread Matthew Flatt
I keep running into sandbox trouble due to file- and
directory-existence tests that are buried inside functions that inspect
Racket's configuration. For example, the contract system runs into
trouble because it uses `path->relative-string/library', which has to
find collections, so it needs to look at the installation's
configuration file, which it may have to find relative to the `racket'
executable (and that's just the tip of the iceberg).

Although I can imagine ways to fix the problem that involve trusting
the modules that search for paths, I wonder whether there's any harm in
simply allowing all file- and directory-existence tests.

Is there a situation where allowing an arbitrary file- or
directory-existence test would be bad?

_
  Racket Developers list:
  http://lists.racket-lang.org/dev