11 ms·

I see a lot of people saying things like "this is why package signing is important" and "we need to know who the developers are" and "we need to audit everythin

I see a lot of people saying things like "this is why package signing is important" and "we need to know who the developers are" and "we need to audit everything." Some of that is true to some degree, but let me ask you this: why do we consider it acceptable that code you install through a package manager implicitly gets to do anything to your system that you can do? That seems silly! Surely we can do better than that? This article from Agoric is extremely relevant here, from a previous such incident (re: the event-stream package on npm): https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even... Put simply: in many cases, the dependencies you install don't need nearly as much authority as we give them right now. Maybe some of these packages need network access (I see a few named "logger" which might be shipping logs remotely) but do they need unrestricted filesystem access? Probably not! (They don't necessarily even need unrestricted network access either; what they're communicating with is likely pretty well-known.)

detaro 6y ago
Indeed, being able to apply capabilities on a package level would be great, but I don't know many languages/environments that implement this as a first-class feature.
- ryukafalz 6y ago
  Yeah. JavaScript is probably the closest to being there (with things like SES[0], LavaMoat[1], etc.) but we're not quite there yet. It's just shocking that this sort of thing is as seemingly obscure as it is; it's like the whole industry has collectively thrown up their hands and said code execution is unavoidably radioactively dangerous. (While simultaneously using package managers that... well.) But it doesn't have to be! [0] https://github.com/Agoric/ses-shim https://github.com/Agoric/ses-shim [1] https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat
- eecc 6y ago
  Java does. Of course it’s never been used systematically and it has received precious little attention to DevOps ergonomics, but the infrastructure is there
  - detaro 6y ago
    I didn't know that. Do you happen to have a link with more details at hand?
    - sid- 6y ago
      https://docs.oracle.com/en/java/javase/15/security/permissions-jdk1.html#GUID-8D0E8306-0DD8-4802-A71E-CFEE9BF8A287 https://docs.oracle.com/en/java/javase/15/security/permissio...
  - bluetech 6y ago
    Java actually doesn't need to add any features for it to support this, it needs to remove them. I recommend reading this excellect article: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ The gist is: Rule #1: All instance variables must be private Rule #2: No mutable static state or statically accessible authority Rule #3: No mutable state accessible across thread boundaries
- dwohnitmok 6y ago
  Safe Haskell is one in this vein (it's lower level and you would apply a capability layer on top), although like other past efforts on this front it's mostly languished in obscurity even among the Haskell community and is used by very few people. The main hope at the moment seems to be JS.
- newhouseb 6y ago
  The WASM ecosystem is exploring this through the use of what they call "nanoprocesses" wherein libraries are wrapped into modules and provided access to nothing by default [1]. This seems to be more of a pattern and consequence of how WASM works than a specific feature. 1. https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/ https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... (ignore the title, it's irrelevant to the excellent explanation that constitutes 70% of the post)
deleted 6y ago
[deleted]
ptx 6y ago
Could you solve this in Java using the SecurityManager stuff that was used to sandbox applets, or is all that considered broken these days? (I'm not sure if you can different SecurityManagers for different parts of the app though.)
- ryukafalz 6y ago
  I'm not familiar enough with Java to have a strong opinion on this, but this HN comment from the linked article mentions that you can only have one SecurityManager per app, so sounds like that's still too coarse-grained: https://news.ycombinator.com/item?id=18599365 https://news.ycombinator.com/item?id=18599365
  - mindcrime 6y ago
    In my experience, the biggest problem with the Java SecurityManager approach is that it's thought of as too difficult to understand / cumbersome to configure (and I'm not saying this belief is wrong), and so most apps either run with no SecurityManager explicitly configured or configure things the "simplest possible way" which usually winds up being approximately equivalent to "anybody can do anything".
  - avereveard 6y ago
    a security manager can examine the call stack and know which class from which package is asking to perform a privileged action within the app; the class object will tell you which loader loaded it, and you can ask the loader the physical location of where the class comes from if you want to be really sure no one has overloaded it.
    - mindcrime 6y ago
      Yes, it's a powerful and flexible mechanism. The problem is - how many people know (in detail) how to configure all of this power so as to take best advantage of it? My subjective perception is a that the answer is something like "a very small percentage of Java developers".
  - 6y ago
easton 6y ago
I believe that Deno (the "successor" to Node being written by Ryan Dahl) is supposed to fix this for server-side JavaScript/TypeScript. It doesn't grant any permissions to anything unless you specifically give them out (so you can say that only a specific module gets access to the filesystem, for instance, and on top of that it can only access /srv and not /etc). https://deno.land/manual@v1.7.2/getting_started/permissions https://deno.land/manual@v1.7.2/getting_started/permissions
- nogbit 6y ago
  I think this is critical. The actual runtime of any code needs to do way more than what it’s doing now. Simply relying on package signing and the like permits trusted but malicious actors. With Deno packages configured well it can really lock down and limit a ton of attack vectors.
  - salawat 6y ago
    >trusted but malicious actors I...think you might have bigger problems going on there. You're tryingto throw a tech solution at a problem that is fundamentally human in nature. That tends to leave nobody satisfied.
    - josephg 6y ago
      Tech solutions are the best solutions when they work! Fighting with your spouse over who does the dishes? Buy a dishwasher! Don’t want your ISP snooping on traffic? Use https / a VPN! Unfortunately, package signing does nothing to protect against the threat vector presented here. The authentication system in npm is working fine. The problem is we put too much trust in software from the internet.
      - salawat 6y ago
        ...Hence my classification of it as a human problem. I apologize, this is a quirk of my personal vernacular. This is a problem that emergently arises out of the way human beings interact with each other socially, even before tool use comes into the picture. Alice has a thing. Bob had a thing that Alice figured would make her life easier so integrates it without looking too hard at it. Alice didn't reallize that by adding Bob's thing, something Alice wanted private was no longer the case even if her primary use case was solved. The technical solution is making Alice's thing include a really onerous to configure permissions framework that takes the work of getting a thing set up and increases the task list from program thing to program and configure permissions for thing. The human solution is to realize you don't know Bob from Adam, or his motivations, and to observe what Bob's thing actually does. Then depending on criticality, remake something similar, or actually take the time to get to know Bob and see if he can make what you want for you under some sort of agreement that facilitates good business and trust all around. You can't be sampling for malicious changes in real-time, so it's all about risk management. The issue in our case, is a lot of these projects are essentially gifts with no active attention paid to them after a certain point. It's a variant of cargo cults. You want this thing? Go here, get that, presto. Businesses, developers, (and their exploiters) like that. The price though is that once a project is abandoned, and the rights transferred to someone you don't know, you have to rerun your risk management calculation again. The thing people should be worried about is all the PHB's (pointy-haired bosses) who just got ammo for their NMIH (Not-Made-In-House) cannons now that supply chain attacks are becoming increasingly visible vectors for attack.
eecc 6y ago
Uh, well the original developers of the Sun JVM didn’t do such a bad job after all when designing it: https://docs.oracle.com/javase/7/docs/technotes/guides/security/smPortGuide.html https://docs.oracle.com/javase/7/docs/technotes/guides/secur...
- WatchDog 6y ago
  Javas security manager system, is usually not in effect for the majority of use cases. While maven/grade dependencies, can't run code on installation, generally once the application is ran/tested, it will be with full user permissions, not under a security manager. The security manager is an additional layer of security that most languages don't have, however Java applets have shown it to be full of holes and generally unsuitable for running untrusted code. The applet security posture has contributed a great deal towards negative opinion towards the language, probably would have been better off never having existed.
  - mike_hearn 6y ago
    There have been hundreds, maybe thousands of local privilege escalation vulnerabilities on Linux. People still find bugs in basic programs like sudo that have been there for decades. Still, nobody would ever suggest that Linux should have the same security approach as Windows 95 or that it's generally unsuitable for running code you didn't write! Sandboxing code is hard, regardless of what language, runtime or operating system approach you use.
- szc 6y ago
  The Sun JVM, as originally implemented, can express operations that are not valid for Java objects. There are parts of the JVM that attempt to constrain opcode sequences to only be from "valid java compilers operating on java objects". In 1996, Java was being overwhelmed by exploits because the mapping of the language to the VM was not well matched. There was a Java summit with lots of interesting people. This summit was also when Sun got confirmation that MicroSoft had quite a few engineers working on an independently implemented runtime. To Sun's credit, they did get rather more serious about Java security -- but they had already created a rocky foundation. It is my opinion, that the business model Sun had "in mind" for Java was a free runtime for everyone that they were in control of, but to make money from selling an "official" Java compiler suite. I do not believe that the Sun Java JVM was created with security in mind.
nahuel0x 6y ago
Giving fine-grained permissions to sandboxed libraries is the way forward, and probably a really good use case for WASM.
bluetech 6y ago
This is so obviously what needs to happen, it's really surprising it's not a feature in all major languages by now. I bet in 10 years time, giving dependencies complete control would seem crazy. Here is an interesting proposal on how to possibly get there in JS with import maps: https://guybedford.com/secure-modular-runtimes https://guybedford.com/secure-modular-runtimes Deno uses ambient permissions for the entire process and unfortunately missed the opportunity to do it right.
deleted 6y ago
[deleted]
safog 6y ago
This is a really nice idea but considering we haven't even solved the relatively simple case of users giving permissions to apps and expecting them to behave responsibly, I'm not optimistic that we can solve the much more challenging case of importing library code. e.g., If someone gives an app the ability to upload photos, it can silently read all photo metadata, upload all photos to a private server instead of uploading just the single photo that the user picked. This can be solved with OS level standard photo pickers but it hasn't been yet. Same with package code. Maybe a package needs network access for stuff it genuinely needs to do. However it can (and probably will) at some point go above and beyond in the amount of data it collects. FB Mobile SDK outage is a good example of this. https://www.bugsnag.com/blog/sdks-should-not-crash-apps https://www.bugsnag.com/blog/sdks-should-not-crash-apps
edejong 6y ago
It sounds like you are interested in a (distributed) capability-based security model. [1] [1] https://enacademic.com/dic.nsf/enwiki/295618 https://enacademic.com/dic.nsf/enwiki/295618
- ryukafalz 6y ago
  Yes, I didn't use the term explicitly in my comment but you're precisely right. ;) Agoric (the company whose blog post I linked to) and the people behind it have done a ton of object capability work over the years.
bryanrasmussen 6y ago
>why do we consider it acceptable that code you install through a package manager implicitly gets to do anything to your system that you can do? I thought it was because operating systems still use access based instead of capabilities based security?
zomgwat 6y ago
Not a complete answer (by any means) but keeping tight control over egress network access helps (I wish it was easier to limit egress access over port 443). Systemd has some capability to restrict access to system resources. I haven't experimented with the capabilities yet so not sure what's all there.
jjn2009 6y ago
Its unfortunate that the proposed realms is still just a proposal. Even still I've heard many arguments that since the method of isolation lives inside JS it cannot be expected to be entirely secure and you would be much better off relying on OS level security primitives, a point that comments I've read so far completely glosses over. I'd love for someone to prove me wrong that this is air tight so we can champion realms at my work. POLA is good to live by regardless if it can be implemented.
linuxftw 6y ago
I'm late to this conversation, but the thing that can restrict "doing anything" on your machine is SELinux.
thw0rted 6y ago
I'm reading through all these responses and it sounds like nobody read the article. Everybody keeps bringing up JVM SecurityManager, or how granular Deno's permission system is, or a syntax for granting runtime permissions to modules (like your Agoric link). That's not what happened here. The actual attack in the article was a post-install script run by the package manager. That means whatever kind of limits you might place on runtime capabilities of the library wouldn't have mattered. You need a system that lets the package installer request granular permissions from the package manager, where the package manager runs the scripts in a sandbox and only explicitly-provided privileges are granted. I don't know of any package managers that support this feature today.

detaro 6y ago

Indeed, being able to apply capabilities on a package level would be great, but I don't know many languages/environments that implement this as a first-class feature.

ryukafalz 6y ago
Yeah. JavaScript is probably the closest to being there (with things like SES[0], LavaMoat[1], etc.) but we're not quite there yet. It's just shocking that this sort of thing is as seemingly obscure as it is; it's like the whole industry has collectively thrown up their hands and said code execution is unavoidably radioactively dangerous. (While simultaneously using package managers that... well.) But it doesn't have to be! [0] https://github.com/Agoric/ses-shim https://github.com/Agoric/ses-shim [1] https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat
eecc 6y ago
Java does. Of course it’s never been used systematically and it has received precious little attention to DevOps ergonomics, but the infrastructure is there
- detaro 6y ago
  I didn't know that. Do you happen to have a link with more details at hand?
  - sid- 6y ago
    https://docs.oracle.com/en/java/javase/15/security/permissions-jdk1.html#GUID-8D0E8306-0DD8-4802-A71E-CFEE9BF8A287 https://docs.oracle.com/en/java/javase/15/security/permissio...
- bluetech 6y ago
  Java actually doesn't need to add any features for it to support this, it needs to remove them. I recommend reading this excellect article: http://habitatchronicles.com/2017/05/what-are-capabilities/ http://habitatchronicles.com/2017/05/what-are-capabilities/ The gist is: Rule #1: All instance variables must be private Rule #2: No mutable static state or statically accessible authority Rule #3: No mutable state accessible across thread boundaries
dwohnitmok 6y ago
Safe Haskell is one in this vein (it's lower level and you would apply a capability layer on top), although like other past efforts on this front it's mostly languished in obscurity even among the Haskell community and is used by very few people. The main hope at the moment seems to be JS.
newhouseb 6y ago
The WASM ecosystem is exploring this through the use of what they call "nanoprocesses" wherein libraries are wrapped into modules and provided access to nothing by default [1]. This seems to be more of a pattern and consequence of how WASM works than a specific feature. 1. https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/ https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al... (ignore the title, it's irrelevant to the excellent explanation that constitutes 70% of the post)

deleted 6y ago

[deleted]

ptx 6y ago

Could you solve this in Java using the SecurityManager stuff that was used to sandbox applets, or is all that considered broken these days? (I'm not sure if you can different SecurityManagers for different parts of the app though.)

ryukafalz 6y ago
I'm not familiar enough with Java to have a strong opinion on this, but this HN comment from the linked article mentions that you can only have one SecurityManager per app, so sounds like that's still too coarse-grained: https://news.ycombinator.com/item?id=18599365 https://news.ycombinator.com/item?id=18599365
- mindcrime 6y ago
  In my experience, the biggest problem with the Java SecurityManager approach is that it's thought of as too difficult to understand / cumbersome to configure (and I'm not saying this belief is wrong), and so most apps either run with no SecurityManager explicitly configured or configure things the "simplest possible way" which usually winds up being approximately equivalent to "anybody can do anything".
- avereveard 6y ago
  a security manager can examine the call stack and know which class from which package is asking to perform a privileged action within the app; the class object will tell you which loader loaded it, and you can ask the loader the physical location of where the class comes from if you want to be really sure no one has overloaded it.
  - mindcrime 6y ago
    Yes, it's a powerful and flexible mechanism. The problem is - how many people know (in detail) how to configure all of this power so as to take best advantage of it? My subjective perception is a that the answer is something like "a very small percentage of Java developers".
- 6y ago

easton 6y ago

I believe that Deno (the "successor" to Node being written by Ryan Dahl) is supposed to fix this for server-side JavaScript/TypeScript. It doesn't grant any permissions to anything unless you specifically give them out (so you can say that only a specific module gets access to the filesystem, for instance, and on top of that it can only access /srv and not /etc). https://deno.land/manual@v1.7.2/getting_started/permissions https://deno.land/manual@v1.7.2/getting_started/permissions

nogbit 6y ago
I think this is critical. The actual runtime of any code needs to do way more than what it’s doing now. Simply relying on package signing and the like permits trusted but malicious actors. With Deno packages configured well it can really lock down and limit a ton of attack vectors.
- salawat 6y ago
  >trusted but malicious actors I...think you might have bigger problems going on there. You're tryingto throw a tech solution at a problem that is fundamentally human in nature. That tends to leave nobody satisfied.
  - josephg 6y ago
    Tech solutions are the best solutions when they work! Fighting with your spouse over who does the dishes? Buy a dishwasher! Don’t want your ISP snooping on traffic? Use https / a VPN! Unfortunately, package signing does nothing to protect against the threat vector presented here. The authentication system in npm is working fine. The problem is we put too much trust in software from the internet.
    - salawat 6y ago
      ...Hence my classification of it as a human problem. I apologize, this is a quirk of my personal vernacular. This is a problem that emergently arises out of the way human beings interact with each other socially, even before tool use comes into the picture. Alice has a thing. Bob had a thing that Alice figured would make her life easier so integrates it without looking too hard at it. Alice didn't reallize that by adding Bob's thing, something Alice wanted private was no longer the case even if her primary use case was solved. The technical solution is making Alice's thing include a really onerous to configure permissions framework that takes the work of getting a thing set up and increases the task list from program thing to program and configure permissions for thing. The human solution is to realize you don't know Bob from Adam, or his motivations, and to observe what Bob's thing actually does. Then depending on criticality, remake something similar, or actually take the time to get to know Bob and see if he can make what you want for you under some sort of agreement that facilitates good business and trust all around. You can't be sampling for malicious changes in real-time, so it's all about risk management. The issue in our case, is a lot of these projects are essentially gifts with no active attention paid to them after a certain point. It's a variant of cargo cults. You want this thing? Go here, get that, presto. Businesses, developers, (and their exploiters) like that. The price though is that once a project is abandoned, and the rights transferred to someone you don't know, you have to rerun your risk management calculation again. The thing people should be worried about is all the PHB's (pointy-haired bosses) who just got ammo for their NMIH (Not-Made-In-House) cannons now that supply chain attacks are becoming increasingly visible vectors for attack.

eecc 6y ago

Uh, well the original developers of the Sun JVM didn’t do such a bad job after all when designing it: https://docs.oracle.com/javase/7/docs/technotes/guides/security/smPortGuide.html https://docs.oracle.com/javase/7/docs/technotes/guides/secur...

WatchDog 6y ago
Javas security manager system, is usually not in effect for the majority of use cases. While maven/grade dependencies, can't run code on installation, generally once the application is ran/tested, it will be with full user permissions, not under a security manager. The security manager is an additional layer of security that most languages don't have, however Java applets have shown it to be full of holes and generally unsuitable for running untrusted code. The applet security posture has contributed a great deal towards negative opinion towards the language, probably would have been better off never having existed.
- mike_hearn 6y ago
  There have been hundreds, maybe thousands of local privilege escalation vulnerabilities on Linux. People still find bugs in basic programs like sudo that have been there for decades. Still, nobody would ever suggest that Linux should have the same security approach as Windows 95 or that it's generally unsuitable for running code you didn't write! Sandboxing code is hard, regardless of what language, runtime or operating system approach you use.
szc 6y ago
The Sun JVM, as originally implemented, can express operations that are not valid for Java objects. There are parts of the JVM that attempt to constrain opcode sequences to only be from "valid java compilers operating on java objects". In 1996, Java was being overwhelmed by exploits because the mapping of the language to the VM was not well matched. There was a Java summit with lots of interesting people. This summit was also when Sun got confirmation that MicroSoft had quite a few engineers working on an independently implemented runtime. To Sun's credit, they did get rather more serious about Java security -- but they had already created a rocky foundation. It is my opinion, that the business model Sun had "in mind" for Java was a free runtime for everyone that they were in control of, but to make money from selling an "official" Java compiler suite. I do not believe that the Sun Java JVM was created with security in mind.

nahuel0x 6y ago

Giving fine-grained permissions to sandboxed libraries is the way forward, and probably a really good use case for WASM.

bluetech 6y ago

This is so obviously what needs to happen, it's really surprising it's not a feature in all major languages by now. I bet in 10 years time, giving dependencies complete control would seem crazy. Here is an interesting proposal on how to possibly get there in JS with import maps: https://guybedford.com/secure-modular-runtimes https://guybedford.com/secure-modular-runtimes Deno uses ambient permissions for the entire process and unfortunately missed the opportunity to do it right.

deleted 6y ago

[deleted]

safog 6y ago

This is a really nice idea but considering we haven't even solved the relatively simple case of users giving permissions to apps and expecting them to behave responsibly, I'm not optimistic that we can solve the much more challenging case of importing library code. e.g., If someone gives an app the ability to upload photos, it can silently read all photo metadata, upload all photos to a private server instead of uploading just the single photo that the user picked. This can be solved with OS level standard photo pickers but it hasn't been yet. Same with package code. Maybe a package needs network access for stuff it genuinely needs to do. However it can (and probably will) at some point go above and beyond in the amount of data it collects. FB Mobile SDK outage is a good example of this. https://www.bugsnag.com/blog/sdks-should-not-crash-apps https://www.bugsnag.com/blog/sdks-should-not-crash-apps

edejong 6y ago

It sounds like you are interested in a (distributed) capability-based security model. [1] [1] https://enacademic.com/dic.nsf/enwiki/295618 https://enacademic.com/dic.nsf/enwiki/295618

ryukafalz 6y ago
Yes, I didn't use the term explicitly in my comment but you're precisely right. ;) Agoric (the company whose blog post I linked to) and the people behind it have done a ton of object capability work over the years.

bryanrasmussen 6y ago

>why do we consider it acceptable that code you install through a package manager implicitly gets to do anything to your system that you can do? I thought it was because operating systems still use access based instead of capabilities based security?

zomgwat 6y ago

Not a complete answer (by any means) but keeping tight control over egress network access helps (I wish it was easier to limit egress access over port 443). Systemd has some capability to restrict access to system resources. I haven't experimented with the capabilities yet so not sure what's all there.

jjn2009 6y ago

Its unfortunate that the proposed realms is still just a proposal. Even still I've heard many arguments that since the method of isolation lives inside JS it cannot be expected to be entirely secure and you would be much better off relying on OS level security primitives, a point that comments I've read so far completely glosses over. I'd love for someone to prove me wrong that this is air tight so we can champion realms at my work. POLA is good to live by regardless if it can be implemented.

linuxftw 6y ago

I'm late to this conversation, but the thing that can restrict "doing anything" on your machine is SELinux.

thw0rted 6y ago

I'm reading through all these responses and it sounds like nobody read the article. Everybody keeps bringing up JVM SecurityManager, or how granular Deno's permission system is, or a syntax for granting runtime permissions to modules (like your Agoric link). That's not what happened here. The actual attack in the article was a post-install script run by the package manager. That means whatever kind of limits you might place on runtime capabilities of the library wouldn't have mattered. You need a system that lets the package installer request granular permissions from the package manager, where the package manager runs the scripts in a sandbox and only explicitly-provided privileges are granted. I don't know of any package managers that support this feature today.