?
Solved

How do you enable Node.JS to spawn a new process that runs inside an SELinux Sandbox?

Posted on 2013-05-17
6
Medium Priority
?
729 Views
Last Modified: 2013-06-01
I am building a Node.JS application that involves redirecting user input into a server-side command.  Of course, that could be catastrophic to security, so I desire to run the child command inside an SELinux sandbox.  (I do not want to run the entire application inside of a sandbox because I want the end users to each have their own workspace on the server.)

For example, for the purpose of demonstration, consider the command `cowsay`.  In order to run a sandboxed cowsay, you need simply `sandbox cowsay`.  Other than the behind-the-scenes security differences, the interface of `sandbox cowsay` should be the same as that of plain `cowsay`.

However, Node.JS responds differently to these two approaches.  Consider the code:

var spawn = require('child_process').spawn;                      
var cmd = spawn("cowsay", ["hello"]); // line A (no sandbox) 
var cmd = spawn("sandbox", ["cowsay", "hello"]); // line B (with sandbox)
cmd.stdout.on("data", function(data){
    console.log("stdout: "+data);
});
cmd.stderr.on("data", function(data){
    console.log("stderr: "+data);
});
cmd.on("exit", function(err){
    console.log("exit: "+err);
});

Open in new window

Here is the output of the version with line A:
$ node run.js
stdout:  _______ 
< hello >
 ------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

exit: 0

Open in new window

but here is the output of the version with line B instead:
$ node run.js
exit: 0

Open in new window

In other words, Node.JS does not seem to read the streams from sandbox's child process.

This behavior is exhibited only when SELinux is in "enforcing" mode.  The sandbox version works fine when SELinux is in "permissive" (non-enforcing) mode.

This test can be performed using any command.  For example, suppose we used the python command interpreter.  What happens here is that the non-sandboxed `python` waits for something to be fed into its stdin from Node.JS, but the sandboxed `python` simply exists with code 0, without waiting.

What needs to happen in order for Node.JS to treat a sandboxed command the same as a non-sandboxed command?
0
Comment
Question by:sffc
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
6 Comments
 
LVL 1

Author Comment

by:sffc
ID: 39212490
I eventually solved the issue.  I posted my solution here.
0
 
LVL 1

Accepted Solution

by:
sffc earned 0 total points
ID: 39213929
The issue seems to involve SELinux stopping libuv (the underpinnings of Node) from reading and writing a UNIX stream socket, which of course is required for Node's non-blocking I/O.  One reason this took so long to find was that this error was being hidden from SELinux's audit by dontaudit rules.

We started by doing the following:

# semodule -DB  ## turns off dontaudit rules
# tail -f /var/log/audit/audit.log

Open in new window

Then in a different terminal, run the application.  A bunch of SELinux audits appear, but most significantly, one that says:

type=AVC msg=audit(1370065734.791:5038): avc:  denied  { read write } for  pid=8887 comm="my_command" path="socket:[1258916]" dev=sockfs ino=1258916 scontext=unconfined_u:unconfined_r:sandbox_t:s0:c98,c807 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket

Open in new window

To make this into a policy, we did the following:

# grep "type=AVC msg=audit(1370065734.791:5038)" /var/log/audit/audit.log  | audit2allow -M unixsocketsandbox
# semodule -i unixsocketsandbox.pp

Open in new window

where `unixsocketsandbox` is a unique name for the policy.  The policy (via `cat unixsocketsandbox.te`) reads as follows:

allow sandbox_t unconfined_t:unix_stream_socket { read write };

Open in new window

After this, the application works as expected, within the limitations of a sandbox.
0

Featured Post

[Webinar] Lessons on Recovering from Petya

Skyport is working hard to help customers recover from recent attacks, like the Petya worm. This work has brought to light some important lessons. New malware attacks like this can take down your entire environment. Learn from others mistakes on how to prevent Petya like worms.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In threads here at EE, each comment has a unique Identifier (ID). It is easy to get the full path for an ID via the right-click context menu. However, we often want to post a short link within a thread rather than the full link. This article shows a…
Q&A with Course Creator, Mark Lassoff, on the importance of HTML5 in the career of a modern-day developer.
Six Sigma Control Plans
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial
Suggested Courses

718 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question