On Thu, May 30, 2013 at 12:01 PM, Shane Carr <[email protected]> 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.
