Received: by 10.66.75.7 with SMTP id y7mr3122663pav.12.1343778016550;
        Tue, 31 Jul 2012 16:40:16 -0700 (PDT)
X-BeenThere: nodejs-dev@googlegroups.com
Received: by 10.68.233.198 with SMTP id ty6ls2687724pbc.2.gmail; Tue, 31 Jul
 2012 16:40:14 -0700 (PDT)
Received: by 10.66.85.231 with SMTP id k7mr3323024paz.38.1343778014502;
        Tue, 31 Jul 2012 16:40:14 -0700 (PDT)
Received: by 10.66.85.231 with SMTP id k7mr3323023paz.38.1343778014487;
        Tue, 31 Jul 2012 16:40:14 -0700 (PDT)
Return-Path: <i...@bnoordhuis.nl>
Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46])
        by gmr-mx.google.com with ESMTPS id vo7si978156pbc.1.2012.07.31.16.40.13
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 31 Jul 2012 16:40:13 -0700 (PDT)
Received-SPF: pass (google.com: domain of i...@bnoordhuis.nl designates 209.85.160.46 as permitted sender) client-ip=209.85.160.46;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of i...@bnoordhuis.nl designates 209.85.160.46 as permitted sender) smtp.mail=i...@bnoordhuis.nl
Received: by mail-pb0-f46.google.com with SMTP id rp8so63332pbb.33
        for <nodejs-dev@googlegroups.com>; Tue, 31 Jul 2012 16:40:13 -0700 (PDT)
        d=google.com; s=20120113;
        h=mime-version:x-originating-ip:in-reply-to:references:date
         :message-id:subject:from:to:content-type:x-gm-message-state;
        bh=HwRl8/MzoUdw51ry+e/idJ6FkgZ4+8ROACHFcMDaDv4=;
        b=pgzBH7jB3hfvg8syktbOgbzTfl4msYAr8MljavQEE0j0wuFYfsq1rXVMujJRbQb+1b
         X0RN/qr4UQNTgnSuUVQwCFplU/e3QYEUSeSKa1F7GPmSVaDfulWs6P6E+w9SqvvVHS22
         Tzm12ghxo04oHZ0G+drzfQw2SVrpn+woPNOGIfcldCQGMRSOTgxqfkAEqoND1WEXbpic
         tR9bu/6U1cLsGgZWnYzvFesuAJ5Dnt2tKbSiPGhHV/a6PfdYKpSVu1n/zmUn9HuJjxve
         4N6neqgZqzw3+TPFj//JbpdvXg/IqlrDBifWEKJj8FBOzKS1oE5L3ygvDAuBNroqQFdl
         M4Vw==
MIME-Version: 1.0
Received: by 10.68.238.68 with SMTP id vi4mr46552978pbc.123.1343778013570;
 Tue, 31 Jul 2012 16:40:13 -0700 (PDT)
Received: by 10.68.44.233 with HTTP; Tue, 31 Jul 2012 16:40:13 -0700 (PDT)
X-Originating-IP: [87.214.96.125]
In-Reply-To: <9519280a-d1f8-49cc-b1ec-7608818ff51f@googlegroups.com>
References: <9519280a-d1f8-49cc-b1ec-7608818ff51f@googlegroups.com>
Date: Wed, 1 Aug 2012 01:40:13 +0200
Message-ID: <CAHQurc_GpmwNPSejZzBHF39abeqVr3pH6xxJe3quL1rWavz...@mail.gmail.com>
Subject: Re: [node-dev] "Hardened" node
From: Ben Noordhuis <i...@bnoordhuis.nl>
To: nodejs-dev@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQknJvU2T1TRJ6v9nPEAh3ev0BF+xFNQsuurIGwREzaaSWuVL/ZThe+SQkrhaDRCy0WKTAyk

On Wed, Aug 1, 2012 at 12:56 AM, MikeS <m...@emotive.com> wrote:
> I'm using node.js as part of a cloud-based, multi-tenanted server
> environment, with each node process specific to one of the tenants.  (Their
> most common job is to communicate between some external system and the
> shared server.)   For security reasons, it's a requirement to keep the node
> processes from interfering with each other, since, in principle, they could
> be running third-party-written code.  After some analysis, we came up with
> the following specific requirements:
>
> Each node processes will be given a file system directory, which will
>
> Contain the JavaScript it runs
>
> Be usable as a scratchpad, e.g. to buffer large datasets read from an
> external system
>
> Other than that, the process will have no access to any other part of the
> file system
>
> Each node process creates a socket that it uses to receive requests from the
> server.  To prevent different node processes from communicating with each
> other directly, the ability of node processes to connect to sockets will be
> restricted.  Access to Unix Domain Sockets will be turned off completely.
> On general principles, Node processes will not be allowed to
>
> kill other processes
> change their default directory
> change their effective user or group id
>
> Node processes will not be allowed to create subprocesses (which might
> overcome the restrictions above).
> Node processes will not be allowed to load native-code extensions (which
> might overcome the restrictions above.)
>
> The only third-party code running in the system will be the node.js
> JavaScript.  In particular, the server that starts up the node.js processes
> is trusted, so this can be implemented by starting node with command-line
> flags that force the behavior described above.  I've defined three:
>
> --restricted-outgoing-addresses address-list takes a comma-separated list of
> IP addresses to which access will be restricted.  This would most commonly
> be all the IP addresses for the current machine.
> --allowed-outgoing-ports port-list takes a comma-separated list of ports to
> which access is allowed even on restricted addresses.  This would represent
> local services to which the node service is granted access.
> --safe-mode implements the other restrictions shown above (file system,
> process restrictions, etc.)
>
> I've forked 0.8.3 and implemented this at
> https://github.com/mikeatemotive/node.js-safe-mode .  I'm quite interested
> in any comments, and in particular on whether there's interest in bringing
> this functionality into node.

No. I appreciate the effort but it sounds too much like PHP's safe
mode and everyone knows how broken that is. Containerization should be
done at the OS level, not the application level.