1. 10
  1.  

  2. 6

    I am extremely pleased that the author and friends have written this post and are working to improve the JS ecosystem. I was going to write a similar blog post and am glad that somebody else did it first.

    I wanted to translate some of this code to Monte, and in the process show off what a module system designed for this sort of POLA isolation looks like when used in practice.

    exports (safeAddExclamation)
    def safeAddExclamation(str :Str) :Str as DeepFrozen { return str + "!" }
    

    This module doesn’t have any import lines, so it doesn’t have any imports, so it cannot do anything worse than exhaust your CPU or memory. (The weight of repeating this caveat has inspired me to look into the aptly-named Pola language as a possible solution.) Additionally, every exported object must be audited by DeepFrozen; this is a proof that the exported object’s AST and closure are transitively immutable. Since all exports are transitively immutable, modules are limited in their ability to sneak functionality into their callers’ programs.

    Monte doesn’t have require(). When this incident first happened, I opined that maybe JS should not have require(), on the sole basis that it spoils static analysis. Monte also keeps access to clocks, timers, random entropy, etc. out of safe scopes, forcing developers to be explicit about passing and using authority.

    1. 4

      This is tagged as cryptocurrencies, but I don’t think that’s really necessary for this post. The attack discussed was going after Bitcoin keys, but that fact is the only cryptocurrency-related part of this post. It’s interesting content, and I hope people read it even if they’re turned off by Bitcoin and friends.

      1. 2

        I think I agree, but I’m less certain this works so perfectly across broader JavaScript ecosystem. Was the module in question kind of a lucky hit that normally required no fs access?

        In Openbsd, efforts to more or less do the same run into the roadblock that every (C) library thinks it needs to do everything and will randomly open files all over the place whenever it feels like it. This hypothetical safeaddezclamation will no doubt require access to /etc/locale and www.unicode.org and so forth to make sure that it adds the correct punctuation mark.

        1. 2

          Shouldn’t it help that JavaScript is a higher-level language, though? It’s reasonable for a C program to open the “file” /dev/fd/2 if it wants to write to stderr, but I think it’s also reasonable to place a restriction on JavaScript programs that if they want access to stderr they have to use a higher-level construct like process.stderr.write or something. This facility in turn could be protected by something like POLA.

          1. 1

            Regarding the Openbsd example, it seems that making these dependencies explicit might lead to improved libraries eventually?

            For the access to /etc/locale, I imagine that this could be done through a call to a locale-function in the standard library. (Assuming there’s a way to bless a library to access the file system even from libraries that don’t have permission themselves…)

            And network access to unicode.org is unexpected enough that I’d be sure to want to know about it as a user of said library.

          2. 2

            POLA is nice; but, what’s being argued for here is capability-based security.

            It’s been a long time coming.

            1. 1

              I think that’s a category mistake. You can use capability based security measures and still grant too many capabilities to agents that don’t need them. You need a policy to determine how to use the capability based security measures. The latter is a required ingredient, but not sufficient.

              1. 2

                I stand 100% corrected. Cheers!

            2. 1

              I’m quite skeptical when it comes to fixing social problems using technology. If you don’t trust code, don’t use it.

              1. 1

                Except people do trust the code when they shouldn’t. Because it makes them “moar agile” and the suits see only costs in hours, not in the risks of future exploits or dependency-bitrot. Claiming that “this is a social problem therefore we shouldn’t address it with technology” has no meaning when the “social problem” is not up for alteration, only the technology is.