Re: [racket-dev] sandbox and file-/directory-existence tests
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
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
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
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