Most active commenters
  • bugtodiffer(3)
  • oblio(3)

←back to thread

Deno 2.4

(deno.com)
133 points hackandthink | 15 comments | | HN request time: 0.618s | source | bottom
Show context
bflesch ◴[] No.44488699[source]
Big fan of deno, congrats on shipping.

From a security standpoint it really icks me when projects prominently ask their users to do the `curl mywebsite.com/foo.sh | sh` thing. I know risk acceptance is different for many people, but if you download a file before executing it, at least you or your antivirus can check what it actually does.

As supply chain attacks are a significant security risks for a node/deno stack application, the `curl | sh` is a red flag that signals to me that the author of the website prefers convenience over security.

With a curl request directly executed, this can happen:

- the web server behind mywebsite.com/foo.sh provides malware for the first request from your IP, but when you request it again it will show a different, clean file without any code

- MITM attack gives you a different file than others receive

Node/deno applications using the npm ecosystem put a lot of blind trust into npm servers, which are hosted by microsoft, and therefore easily MITM'able by government agencies.

When looking at official docs for deno at https://docs.deno.com/runtime/getting_started/installation/ the second option behind `curl | sh` they're offering is the much more secure `npm install -g deno`. Here at least some file integrity checks and basic malware scanning are done by npm when downloading and installing the package.

Even though deno has excellent programmers working on the main project, the deno.land website might not always be as secure as the main codebase.

Just my two cents, I know it's a slippery slope in terms of security risk but I cannot say that `curl | sh` is good practice.

replies(10): >>44488723 #>>44488744 #>>44488758 #>>44488836 #>>44489041 #>>44489128 #>>44489256 #>>44489488 #>>44489530 #>>44489730 #
1. bugtodiffer ◴[] No.44488758[source]
using deno isn't good security practice, their sandbox is implemented like stuff from the 90s
replies(3): >>44488797 #>>44488852 #>>44488903 #
2. bflesch ◴[] No.44488797[source]
Is node "sandbox" different? Does it even have a sandbox?
replies(1): >>44494016 #
3. homebrewer ◴[] No.44488852[source]
If you're writing server stuff, at the coarse-grained level of isolation that Deno provides you're better off using just about anything else and restricting access to network/disks/etc through systemd. Unlike Deno, it can restrict access to specific filesystem paths and network addresses (whitelist/blacklist, your choice), and you're not locked into using just Deno and not forced to write JS/TS.

See `man systemd.exec`, `systemd-analyze security`, https://wiki.archlinux.org/title/Systemd/Sandboxing

replies(3): >>44489232 #>>44489298 #>>44489306 #
4. oblio ◴[] No.44488903[source]
Can you expand on this please? Also curious which 90s tech there inspired by.
replies(1): >>44488981 #
5. bugtodiffer ◴[] No.44488981[source]
It is matching strings instead of actually blocking things. That's how sandboxes were implemented when I was a kid.

E.g. --allow-net --deny-net=1.1.1.1

You cannot fetch "http://1.1.1.1" but any domain that resolves to 1.1.1.1 is a bypass...

It's crap security

replies(3): >>44489091 #>>44489110 #>>44493725 #
6. jeltz ◴[] No.44489091{3}[source]
That isn't 90s security, that is just bad code. And bad code was written in the 90s and is still written today.
7. whizzter ◴[] No.44489110{3}[source]
If security principles are important they should be on a deny-default basis with allow-lists rather than the other way around.

If the deno runtime implements the fetch module itself, then post-resolution checking definitely should be done though. It's more of an bug though than a principled security lapse.

replies(1): >>44491115 #
8. crabmusket ◴[] No.44489232[source]
Deno can restrict access to filesystem files or directories, and to particular network domains, see docs for examples. https://docs.deno.com/runtime/fundamentals/security/#file-sy...

However in general I don't think Deno's permission system is all that amazing, and I am annoyed that people call it "capability-based" sometimes (I don't know if this came from the Deno team ever or just misinformed third parties).

I do like that "deno run https://example.com/arbitrary.js" has a minimum level of security by default, and I can e.g. restrict it to read and write my current working dir. It's just less helpful for combining components of varying trust levels into a single application.

9. vorticalbox ◴[] No.44489298[source]
> Unlike Deno, it can restrict access to specific filesystem paths and network addresses

deno can do this via --(allow/deny)-read and --(allow/deny)-write for the file system.

You can do the same for net too

https://docs.deno.com/runtime/fundamentals/security/#permiss...

10. mk12 ◴[] No.44489306[source]
Bubblewrap is another convenient sandboxing tool for Linux: https://wiki.archlinux.org/title/Bubblewrap
11. bugtodiffer ◴[] No.44491115{4}[source]
The thing is that this applies to all parts of the sandbox https://secfault-security.com/blog/deno.html
12. oblio ◴[] No.44493725{3}[source]
Ah, so by default it's default deny everything but once you need to open up categories, you can't just allow exact what you need in that category? You have to allow the entire category and then deny everything you don't want/need?

That's a bit of a silly model.

replies(1): >>44493924 #
13. throwitaway1123 ◴[] No.44493924{4}[source]
> you can't just allow exact what you need in that category? You have to allow the entire category and then deny everything you don't want/need?

No, you can allow access to specific domains, IP addresses, filesystem paths, environment variables, etc, while denying everything else by default. You can for instance allow access to only a specific IP (e.g. `deno run --allow-net='127.0.0.1' main.ts`), while implicitly blocking every other IP.

What the commenter is complaining about is the fact that Deno doesn't check which IP address a domain name actually resolves to using DNS resolution. So if you explicitly deny '1.1.1.1', and the script you're running fetches from a domain with an A record pointing to '1.1.1.1', Deno will allow it.

In practice, I usually use allow lists rather than deny lists, because I very rarely have an exhaustive list on hand of every IP address or domain I'm expecting a rogue script to attempt to access.

replies(1): >>44494381 #
14. throwitaway1123 ◴[] No.44494016[source]
Node does have a permissions system, but it's opt in. Many runtimes/interpreters either have no sandbox at all, or they're opt in, which is why Deno's sandbox is an upgrade, even if it's not as hardened as iptables or Linux namespaces.
15. oblio ◴[] No.44494381{5}[source]
Yeah, that was my point, default deny vs default allow.

If you can default deny, then you're good. It's kind of a junior sysadmin mistake, otherwise, I would say.