Thanks again for the advice. Telling SELinux to permit the two AVC lines
from the pastebin actually did not solve the problem, but what did solve
the problem was revealed only after we turned off the "dontaudit" feature
of SELinux. The policy that enables Node to spawn a process inside a
sandbox seems to be:
allow sandbox_t unconfined_t:unix_stream_socket { read write };
I posted more detail about this over on Stack
Overflow<http://stackoverflow.com/a/16870251>.
We hope that this policy exception doesn't open any vulnerabilities.
Sam: We initially chose SELinux because it supposedly has lower overhead
than something like chroot. However, we didn't consider running Octave
from a restricted shell. That would still need the overhead of a chroot,
though. This is definitely something we'll try if we can't solve some
other SELinux issues that popped up today (e.g., sending a SIGINT to the
child process).
The next question is how well this Sandbox business will scale! We may
need to move the shell processing off to sibling servers, but that is a
question beyond the scope of this thread. :-)
On Thursday, May 30, 2013 6:25:43 AM UTC-5, Ben Noordhuis wrote:
>
> On Thu, May 30, 2013 at 12:01 PM, Shane Carr <[email protected]<javascript:>>
> wrote:
> > Thank you everyone for your advice. Here are the results of some more
> > tests.
> >
> > No useful information is printed to STDERR, and no error events are
> fired.
> >
> > SELinux prints no errors to its logfile when the script is run under
> > enforcing mode. However, when it is in permissive mode (i.e., when the
> > application is working), it prints the following errors:
> > http://pastebin.com/Y0uzzCuG
> >
> > I compared the result of `strace node app.js` between executions when
> > SELinux is enforcing and when SELinux is permissive. The "permissive"
> > version ends with the shell waiting for input, with a line reading
> > epoll_wait(5, but the "enforcing" version completes that line with
> > epoll_wait(5, {{EPOLLIN|EPOLLHUP, {u32=10, u64=10}}, {EPOLLIN|EPOLLHUP,
> > {u32=12, u64=12}}}, 1024, 4294967295) = 2 followed by some more messages
> > that you can see here: http://pastebin.com/4eCsp68V
> >
> > One thing that caught my eye in the strace output was "ENOTTY", but
> since
> > this appears in both the "permissive" and the "enforcing" versions, it
> is
> > most likely not the source of the issue.
> >
> > This low-level tracing is unfortunately not my, or my team's, strong
> suit.
> > Are any of these errors meaningful? How could we go about determining
> the
> > cause and remedy of the SELinux errors and the strace output?
> >
> > It is crucial to our Node application for the shell communication to
> work.
> > The issue is that our end user, who may be untrusted, will have the
> ability
> > to execute commands inside a shell that runs on our server. (A large
> part
> > of the application is essentially a terminal screen.) Since this is a
> > textbook example of what not to do for the sake of security, we need to
> run
> > the shell in some sort of sandbox that isolates it from the rest of the
> > system. The SELinux Sandbox approach should suit our needs, if we can
> get
> > it working. Do you think investing the time to learn and configure an
> > alternative solution (AppArmor, OpenBSD Jails, etc) would be worthwhile?
> > Are there any other good solutions that we may have missed?
>
> It looks like your policy is too restrictive for node.js.
>
> type=AVC msg=audit(1369905726.607:4639): avc: denied { ioctl } for
> pid=4715 comm="my_shell" path="socket:[1136443]" dev=sockfs
> ino=1136443 scontext=unconfined_u:unconfined_r:sandbox_t:s0:c155,c475
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=unix_stream_socket
>
> That's SELinux saying it denied what is likely an ioctl(FIONBIO)
> syscall, which is what node.js (or rather, libuv) uses to switch
> sockets to non-blocking mode.
>
> I don't know if switching to another security framework will help you
> much. You still need to strike the right balance between security and
> usability.
>
--
--
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
