FAQ
Hi,

Right now I'm working on a sandbox library for node.js. I'd most likely be
using vm.runInNewContext to prevent any unwanted methods (eg process.kill)
from becoming accessible, and the untrusted code would run in a different
node process.

I'm looking into the possibility of enabling code to call a wrapped
'require()' for loading a restricted set of modules (eg 'crypto' or
'util'), or even exposing wrapped versions of 'net' or 'fs' that restrict
their use to certain paths/addresses. This is mainly for performance
reasons, otherwise I'd do I/O in the main process.

I'm a bit concerned that somehow, 'process.binding()' is going to become
accessible to the untrusted code if I expose a module to it. Is this an
irrational concern, or would it be more secure to wrap process.binding in
the global scope of my sandbox before running the untrusted code?

Thanks again!

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Search Discussions

  • Ben Noordhuis at Jul 3, 2012 at 2:53 am

    On Tue, Jul 3, 2012 at 4:27 AM, Will Riley wrote:
    Hi,

    Right now I'm working on a sandbox library for node.js. I'd most likely be
    using vm.runInNewContext to prevent any unwanted methods (eg process.kill)
    from becoming accessible, and the untrusted code would run in a different
    node process.

    I'm looking into the possibility of enabling code to call a wrapped
    'require()' for loading a restricted set of modules (eg 'crypto' or 'util'),
    or even exposing wrapped versions of 'net' or 'fs' that restrict their use
    to certain paths/addresses. This is mainly for performance reasons,
    otherwise I'd do I/O in the main process.

    I'm a bit concerned that somehow, 'process.binding()' is going to become
    accessible to the untrusted code if I expose a module to it. Is this an
    irrational concern, or would it be more secure to wrap process.binding in
    the global scope of my sandbox before running the untrusted code?

    Thanks again!
    The vm module is *not* for running untrusted code. A sandbox != secure jail.

    We warn about it in the docs but maybe we have to be more explicit
    about it because questions like yours come up often.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Will Riley at Jul 3, 2012 at 3:16 am
    Ah, I see. I saw in the docs that it says "safely running untrusted code
    requires a separate process", but could you elaborate on that? Would it be
    better to use vanilla v8 for something like this?
    On Monday, July 2, 2012 10:53:26 PM UTC-4, Ben Noordhuis wrote:
    On Tue, Jul 3, 2012 at 4:27 AM, Will Riley wrote:
    Hi,

    Right now I'm working on a sandbox library for node.js. I'd most likely be
    using vm.runInNewContext to prevent any unwanted methods (eg
    process.kill)
    from becoming accessible, and the untrusted code would run in a different
    node process.

    I'm looking into the possibility of enabling code to call a wrapped
    'require()' for loading a restricted set of modules (eg 'crypto' or 'util'),
    or even exposing wrapped versions of 'net' or 'fs' that restrict their use
    to certain paths/addresses. This is mainly for performance reasons,
    otherwise I'd do I/O in the main process.

    I'm a bit concerned that somehow, 'process.binding()' is going to become
    accessible to the untrusted code if I expose a module to it. Is this an
    irrational concern, or would it be more secure to wrap process.binding in
    the global scope of my sandbox before running the untrusted code?

    Thanks again!
    The vm module is *not* for running untrusted code. A sandbox != secure
    jail.

    We warn about it in the docs but maybe we have to be more explicit
    about it because questions like yours come up often.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fedor Indutny at Jul 3, 2012 at 3:21 am
    Well, you may use separate node process, but you should run in in chroot or
    jail if you want a real safity here.

    Cheers,
    Fedor.


    On Mon, Jul 2, 2012 at 8:16 PM, Will Riley wrote:

    Ah, I see. I saw in the docs that it says "safely running untrusted code
    requires a separate process", but could you elaborate on that? Would it be
    better to use vanilla v8 for something like this?

    On Monday, July 2, 2012 10:53:26 PM UTC-4, Ben Noordhuis wrote:
    On Tue, Jul 3, 2012 at 4:27 AM, Will Riley wrote:
    Hi,

    Right now I'm working on a sandbox library for node.js. I'd most likely be
    using vm.runInNewContext to prevent any unwanted methods (eg
    process.kill)
    from becoming accessible, and the untrusted code would run in a different
    node process.

    I'm looking into the possibility of enabling code to call a wrapped
    'require()' for loading a restricted set of modules (eg 'crypto' or 'util'),
    or even exposing wrapped versions of 'net' or 'fs' that restrict their use
    to certain paths/addresses. This is mainly for performance reasons,
    otherwise I'd do I/O in the main process.

    I'm a bit concerned that somehow, 'process.binding()' is going to become
    accessible to the untrusted code if I expose a module to it. Is this an
    irrational concern, or would it be more secure to wrap process.binding in
    the global scope of my sandbox before running the untrusted code?

    Thanks again!
    The vm module is *not* for running untrusted code. A sandbox != secure
    jail.

    We warn about it in the docs but maybe we have to be more explicit
    about it because questions like yours come up often.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Azer Koçulu at Jul 3, 2012 at 3:39 am
    Hi,

    OneJS (http://github.com/azer/onejs) aims to do a very similar job by
    bundling. It wraps all the modules in your project and provides them
    custom implementations of global NodeJS functions & objects (require,
    process, console etc..);

    https://github.com/azer/onejs/blob/master/templates/module.js#L6

    Right now its NodeJS emulation is not enough for your purpose. It
    needs better process implementation and the emulations of the core
    libraries that need to be inside of sandbox.

    Best,

    Azer
    On Mon, Jul 2, 2012 at 8:20 PM, Fedor Indutny wrote:
    Well, you may use separate node process, but you should run in in chroot or
    jail if you want a real safity here.

    Cheers,
    Fedor.


    On Mon, Jul 2, 2012 at 8:16 PM, Will Riley wrote:

    Ah, I see. I saw in the docs that it says "safely running untrusted code
    requires a separate process", but could you elaborate on that? Would it be
    better to use vanilla v8 for something like this?

    On Monday, July 2, 2012 10:53:26 PM UTC-4, Ben Noordhuis wrote:
    On Tue, Jul 3, 2012 at 4:27 AM, Will Riley wrote:
    Hi,

    Right now I'm working on a sandbox library for node.js. I'd most likely
    be
    using vm.runInNewContext to prevent any unwanted methods (eg
    process.kill)
    from becoming accessible, and the untrusted code would run in a
    different
    node process.

    I'm looking into the possibility of enabling code to call a wrapped
    'require()' for loading a restricted set of modules (eg 'crypto' or
    'util'),
    or even exposing wrapped versions of 'net' or 'fs' that restrict their
    use
    to certain paths/addresses. This is mainly for performance reasons,
    otherwise I'd do I/O in the main process.

    I'm a bit concerned that somehow, 'process.binding()' is going to
    become
    accessible to the untrusted code if I expose a module to it. Is this an
    irrational concern, or would it be more secure to wrap process.binding
    in
    the global scope of my sandbox before running the untrusted code?

    Thanks again!
    The vm module is *not* for running untrusted code. A sandbox != secure
    jail.

    We warn about it in the docs but maybe we have to be more explicit
    about it because questions like yours come up often.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Rehan Iftikhar at Jul 3, 2012 at 5:26 am
    This is a talk from 2012 RubyConfIndia where two guys talk about sandboxing
    Ruby on the server: http://www.youtube.com/watch?v=ntIzf9onRqA

    Some of the stuff is Ruby specific, but there is a lot of good Linux stuff
    in there too.
    On Monday, July 2, 2012 8:20:42 PM UTC-7, Fedor Indutny wrote:

    Well, you may use separate node process, but you should run in in chroot
    or jail if you want a real safity here.

    Cheers,
    Fedor.


    On Mon, Jul 2, 2012 at 8:16 PM, Will Riley wrote:

    Ah, I see. I saw in the docs that it says "safely running untrusted code
    requires a separate process", but could you elaborate on that? Would it be
    better to use vanilla v8 for something like this?

    On Monday, July 2, 2012 10:53:26 PM UTC-4, Ben Noordhuis wrote:

    On Tue, Jul 3, 2012 at 4:27 AM, Will Riley <hapticflow@gmail.com>
    wrote:
    Hi,

    Right now I'm working on a sandbox library for node.js. I'd most likely be
    using vm.runInNewContext to prevent any unwanted methods (eg
    process.kill)
    from becoming accessible, and the untrusted code would run in a different
    node process.

    I'm looking into the possibility of enabling code to call a wrapped
    'require()' for loading a restricted set of modules (eg 'crypto' or 'util'),
    or even exposing wrapped versions of 'net' or 'fs' that restrict their use
    to certain paths/addresses. This is mainly for performance reasons,
    otherwise I'd do I/O in the main process.

    I'm a bit concerned that somehow, 'process.binding()' is going to become
    accessible to the untrusted code if I expose a module to it. Is this an
    irrational concern, or would it be more secure to wrap process.binding in
    the global scope of my sandbox before running the untrusted code?

    Thanks again!
    The vm module is *not* for running untrusted code. A sandbox != secure
    jail.

    We warn about it in the docs but maybe we have to be more explicit
    about it because questions like yours come up often.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Marcel Laverdet at Jul 3, 2012 at 5:50 am
    With all do respect you are in over your head :)

    If you want to take a stab at this for real take a peek at google-caja
    On Mon, Jul 2, 2012 at 9:27 PM, Will Riley wrote:

    Hi,

    Right now I'm working on a sandbox library for node.js. I'd most likely be
    using vm.runInNewContext to prevent any unwanted methods (eg process.kill)
    from becoming accessible, and the untrusted code would run in a different
    node process.

    I'm looking into the possibility of enabling code to call a wrapped
    'require()' for loading a restricted set of modules (eg 'crypto' or
    'util'), or even exposing wrapped versions of 'net' or 'fs' that restrict
    their use to certain paths/addresses. This is mainly for performance
    reasons, otherwise I'd do I/O in the main process.

    I'm a bit concerned that somehow, 'process.binding()' is going to become
    accessible to the untrusted code if I expose a module to it. Is this an
    irrational concern, or would it be more secure to wrap process.binding in
    the global scope of my sandbox before running the untrusted code?

    Thanks again!

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupnodejs @
categoriesnodejs
postedJul 3, '12 at 2:46a
activeJul 3, '12 at 5:50a
posts7
users6
websitenodejs.org
irc#node.js

People

Translate

site design / logo © 2017 Grokbase