[HN Gopher] How Shopify Uses WebAssembly Outside of the Browser
___________________________________________________________________
How Shopify Uses WebAssembly Outside of the Browser
Author : oedmarap
Score : 207 points
Date : 2020-12-19 10:54 UTC (12 hours ago)
(HTM) web link (shopify.engineering)
(TXT) w3m dump (shopify.engineering)
| sradman wrote:
| The underlying platform is ahead-of-time compiled WebAssembly but
| AssemblyScript, a variant of TypeScript, will be the only
| supported language:
|
| > Theoretically any language with a Wasm target can be supported,
| but the effort developers spend to conform to our API is better
| focused on solving problems for merchants. That's why we've
| chosen to provide first class support to a single language that
| includes tools that get developers up and running quickly.
| mfer wrote:
| I think that misses part of the point.
|
| WASM meets their feature needs. WASM is at the core of it.
|
| But, they needed a widely accessible language to tell people to
| use. This helps with examples and guidance. They chose
| AssemblyScript due to their customers being familiar with JS.
|
| It looks like I could write what I need in Go or Rust, for
| example, and build for WASM. They're just not putting that up
| front. This is about making an easy path for most people.
|
| The way it's put together is about n making their customers
| successful rather than building all that's possible
| johnnycerberus wrote:
| Like always, browsers are a funny ecosystem and very
| unpredictable. In all this time I thought that I could see a
| rise in the adoption of C and Rust libs by the community
| through WASM but now instead we are building around
| AssemblyScript. Touche.
| grayrest wrote:
| I've spent a good amount of time this last year playing
| around with WASM options in anticipation of it being a major
| runtime environment for cloud computing.
|
| Rust has the most developed ecosystem but the best experience
| I've had otherwise was with Zig. It's reasonably easy to
| write and can produce excellent final wasm size. The only
| problem is that the compiler is currently exporting every
| public symbol in the standard library but when I hacked up
| the compiler to only export a hard coded list of symbols I
| got ~150 bytes for add (the WASM hello world) and easily sub
| 1k for the type of modules the post is discussing.
| enos_feedler wrote:
| Yes, funny ecosystem and unpredictable because smart people
| contribute innovative and interesting things. This is the
| best feature of an open, truly shared ecosystem. Everyone
| owns it and feel safe contributing to it. The web rules!
| mekkkkkk wrote:
| I wish I could share your enthusiasm. Good on you. To me
| the web of today is an ever-expanding ball of shit being
| rolled in different directions by giant corporations. I
| agree it's fun to work with, but it isn't healthy.
| remram wrote:
| We just have to compile Rust and C to AssemblyScript, a la
| asm.js, and come full circle (again).
| coding_lobster wrote:
| It's interesting that this seems on one hand "unpredictable"
| while also being logical. If a company has employees familiar
| with TypeScript (or even JS) and they have to make a choice
| between yet another flavor of that or a new language like
| C/Rust... well the choice is understandable. Once again the
| path of least resistance to a new web technology ended up
| being JavaScript - it just wasn't immediately obvious when
| WASM first emerged.
| HoolaBoola wrote:
| I know I'm deliberately misinterpreting you, but
|
| > a new language like C
|
| is a funny thought ^_^
| woodpanel wrote:
| A JavaScript SuperSet becoming the de facto standard of
| writing for WASM - I think one can file this under ,,worse
| is better".
| robertlagrant wrote:
| I'm keen on Kotlin Multiplatform. Seems like a pipe dream
| that might have legs.
| xtiansimon wrote:
| This is PR about Shopify's use/promise of WebAssembly--cool. I
| get WebAssembly tech is cool.
|
| I'm interested why Shopify is practically the only sales platform
| that gets 'airtime' at HN.
|
| Is this because partner apps are using Ruby? Does it have
| something to do with the governance of Shopify? Community of
| Canadians on HN?
|
| I have some experience with Square, and a few others.
|
| I'm an interested party.
| christophilus wrote:
| Amazon gets lots of airtime and is a Shopify competitor. Stripe
| gets lots of airtime and is a Shopify competitor.
|
| Anyway, Shopify's engineering blogs can be worthwhile, so they
| make it to the front page. They do interesting work at pretty
| big scale, provide in depth writeups from time to time, and
| folks like me enjoy reading them. I see nothing suspicious
| about it.
| xtiansimon wrote:
| > "I see nothing suspicious about it."
|
| I didn't intend to imply anything of the sort. I gather from
| your response including Amazon you might have a different
| perspective.
|
| I'm interested in sales platforms for small business retail.
| Platforms which let business owners put a store on the web
| and maintain their own website design. Shopify's turn-key
| solution lets you have a stores without all of the Platform
| cruff. You can seel goods on Amazon, but you're just a
| another 'seller' under the branding of Amazon.com (unless
| there is another competing service I'm unaware of).
|
| Personally, I get to see a lot of small businesses from the
| Admin side. And Shopify's partner platform is one of the most
| robust. Pricing is competitive (for the businesss) and
| they're very developer friendly.
|
| No. I really like Shopify, and I was curious why others
| _like_ it so much.
|
| haha. I understand where you might default to thinking I'm
| suspicious. We're all suspicious. And I see a lot of
| businesses who go full-in on a platform (POS, online retail)
| and when it comes to getting financial reports or API access
| you might want, they are unhelpful and very costly. (Don't
| get me started on Third-Party Online Ordering Services like
| DoorDash or Ubereats).
| hobofan wrote:
| > Stripe gets lots of airtime and is a Shopify competitor.
|
| Barely. AFAIK Shopify Payments is built on top of Stripe.
| They only compete on their Capital products, though given
| that most of Shopify's financial products seem to be built on
| Stripe, I'm not even sure if that's true.
| sradman wrote:
| Maybe because it is the largest platform alternative to Amazon
| [1]:
|
| > The company reported that it had more than 1,000,000
| businesses in approximately 175 countries using its platform as
| of June 2019. The total gross merchandise volume exceeded US$61
| billion for calendar 2019.
|
| [1] https://en.wikipedia.org/wiki/Shopify
| [deleted]
| NicoJuicy wrote:
| An interested party in Ecom or ..?
| xtiansimon wrote:
| Not sure why you're downvoted. I'm in retail small business.
| Easy to get started on a turn-key platform, but due to
| different governance strategies they are more or less
| cooperative about their deficiencies.
| louis-paul wrote:
| Do Shopify's competitors produce similarly high-quality
| engineering content? (if you know some, please link!)
| bdcravens wrote:
| Bigcommerce does have a developer blog, but it seems a bit
| more limited in scope:
|
| https://medium.com/bigcommerce-developer-blog
| gravitas wrote:
| Since we're here talking about Shopify - nearly every small shop
| (1-10 person makers) I buy from who uses the platform could not
| (in the past 30 days):
|
| (a) change the email address associated with an existing account
| with history, and
|
| (b) could not delete or change or transfer the orders from the
| old account to the new
|
| I'm working through an email change and have discovered the above
| via hundreds of my logins - Shopify by far is the largest defunct
| platform which locks your account in using an email address,
| neither the user nor admins can "fix" it. All shop owners
| indicate to me they've emailed Support and gotten no help, every
| solution has been "just make a new account".
| tuwtuwtuwtuw wrote:
| What's the problem with making a new account? Should take a few
| minutes at most?
| gravitas wrote:
| Losing years worth of order history with that vendor? Having
| ghost accounts in a vendor database you can't delete, which
| has your previous order's PII (home address, etc.) tied to?
| The problem is not making a new account, it's appropriately
| dealing with the one containing personal information you're
| leaving behind.
| jeromegv wrote:
| You can't change the email on existing accounts however you
| can definitely delete it.
|
| See the docs https://help.shopify.com/en/manual/your-
| account/privacy/GDPR...
|
| Their account management is definitely poor. But you seem
| to make it a bigger deal than it is. You don't have to lose
| the order history, even if you don't have access to the
| email anymore nothing would prevent you from logging again
| with the user/pass. And the order history is really the
| only valuable info... you can also save the email with your
| receipt. It's not ideal but again, how much it actually
| impacts your life is about close to nothing. Request the
| account to be deleted under GDPR and then save the emails
| with your order history.
| gravitas wrote:
| > You can't change the email on existing accounts however
| you can definitely delete it.
|
| I am an end user and cannot do anything other than email
| the shop support and hope. I am not a resident of EU or
| California, you might be surprised at the vast number of
| websites which tell you to go pound sand if you try and
| delete your account. As a user, you can do nothing but
| hope someone deletes something for you if they feel like
| it; not all shop owners bother to respond as well, adding
| another layer of consternation.
|
| > But you seem to make it a bigger deal than it is.
|
| You seem to lack empathy for how other people are
| sensitive to their PII (which in this case may and does
| include credit card purchase information, shipping
| addresses and other "I really don't want this floating
| around more than I need it to be" information about my
| life) being retained by Shopify based stores.
|
| The GDPR you keep leaning on to support your reply means
| nothing to a vast majority of the world and many sites
| happily only perform the minimum required actions
| required by law for those to whom it does apply.
| twic wrote:
| So how about garbage collection?
|
| WASM doesn't have GC in the machine model, right? So either
| customers have to use a language with manual memory management,
| which is hard work, or use one with GC and then compile the
| collector into their binaries, which means bloat, and possibly a
| sub-par GC.
|
| I guess what I'm saying is that it seems like it would have been
| better to have used a JVM.
| __s wrote:
| https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
| twic wrote:
| Something like this seems really important to (some branches
| of) the future of WASM, but this is still just a proposal,
| right?
| azakai wrote:
| It is still a proposal, but it's one of the proposals most
| worked on atm, there's a lot of activity.
| imtringued wrote:
| How would that work? Secure multi tenancy is a difficult
| problem in its own right. You would now have to build a
| security layer outside the JVM because the JVM is exposing too
| many interfaces. You can use containers but the amount of
| interfaces a container exposes is still high enough that a
| container escape is possible. Then you need a security layer on
| top of containers based on VMs. At this point rolling your own
| security solution is either going to be highly inefficient
| because you are allocating too many resources to individual
| customers or expensive because developing infrastructure
| management to stay secure doesn't make your company more
| profitable. Your last hope would be to use an off the shelf
| solution like firecracker to run each JVM in a VM.
|
| Alternatively you can just use a runtime that is sandboxed by
| default and avoid the cat and mouse game.
| martin_drapeau wrote:
| Could someone eligthen me. Why not just use JavaScript? It is
| being used by Cloudflare on the edge, and AWS lambda. Why need to
| go to WASM?
| enriquto wrote:
| The issue is quite symmetrical, isn't it? Somebody could ask:
| why not use just WASM? Why need to go to JavaScript?
|
| This is a better question, actually, if you already have a
| codebase in another language that can you can easily compile to
| wasm, but not to javascript.
| rattray wrote:
| Because as the article states, JavaScript is widely used by
| their plugin developers, while AssemblyScript is still
| nascent (little-used, missing features, has bugs).
| runawaybottle wrote:
| Like what? This is like me saying I have a mostly html/css/js
| website, and I just need it converted to a native Android
| app.
|
| Well no right? I have website. I don't have mobile app that
| just needs to switch platforms.
|
| Do you have a website built in another language already? Then
| sure, all you need to do compile it via WASM. What I bet most
| of you have is a program for a totally different platform. In
| that case, you have to redo it, so why not just do it right.
| alquemist wrote:
| * Predictable performance.
|
| * A wide ecosystem of mature language toolchains.
|
| * Simplicity: JS implementation contain sophisticated JITs,
| which are harder to prove correct compared to a simple ASM
| translator.
|
| * Portability: not tied to a specific HW architecture.
| jariel wrote:
| ? Those are reasons to use JS not WASM.
|
| "A wide ecosystem of mature language toolchains." - yes, for
| Javascript, not for WASM, which isn't deployed really
| anywhere in production and there aren't even best practices
| for it.
|
| What language are devs going to even write these scripts in?
| That's not clear.
|
| "Simplicity" - nothing is more 'simple' than JS, which is why
| it's used the world over.
|
| "Portability" - again, nothing more portable than JS.
|
| The reasons to use WASM are 'performance' along with 'black
| box' - but in most cases performance is not necessary and the
| black box for all intents and purposes exists with v8.
| alquemist wrote:
| I am not following WASM closely, but it appears to be
| deployed in all modern browsers: Chrome, Firefox, Safari,
| Edge. That counts as 'large scale production deployment',
| even if there aren't that many websites that take advantage
| of this capability (yet?). https://caniuse.com/wasm
| MaxBarraclough wrote:
| > "Simplicity" - nothing is more 'simple' than JS, which is
| why it's used the world over.
|
| Not in terms of implementing the language.
| discreteevent wrote:
| Not in terms of using the language either. And the reason
| it is used the world over is because it was dictated to
| developers by browser makers. That's the single and only
| reason.
| x86_64Ubuntu wrote:
| How often does portability ever appear as a tie-breaker
| between to different languages?
| rattray wrote:
| For clarity, do you work at Shopify? These all sound like
| valid reasons, I'm just curious if they're the ones that
| motivated the Scripts team at Shopify.
| [deleted]
| sradman wrote:
| We are talking about two alternative architectures, Cloudflare
| Workers and Fastly Compute@Edge, solving the same problem: how
| to run server-side untrusted code. Cloudflare runs a sandboxed
| V8 runtime in-process with its Nginx servers while Fastly chose
| a Function-as-Service platform using Lucet compiled WebAssembly
| modules with minimal runtime and fast startup. Fastly's Varnish
| servers invoke FaaS modules and it sounds like Shopify's Ruby
| centric platform is better suited to this architecture.
| kentonv wrote:
| > Cloudflare runs a sandboxed V8 runtime in-process with its
| Nginx servers
|
| Maybe nitpicking, but that's not quite right. The Workers
| Runtime is a separate process from nginx and is inside a
| heavy second-layer sandbox separating it from the rest of the
| system. Multiple Workers Runtime instances exist on each
| machine to serve different tiers of customers, and each
| instance may additionally create further subprocesses to
| provide extra sandboxing adaptively.
|
| Here's a diagram: https://blog.cloudflare.com/mitigating-
| spectre-and-other-sec...
|
| (In that diagram, the "Inbound/Outbound HTTP Proxy" boxes
| are, at least at present, nginx, but the big middle box is a
| new server architecture written from scratch.)
| sradman wrote:
| That is not nitpicking at all. Definitely not in-process.
| Thanks for pointing that out.
| robertlagrant wrote:
| Aah, that's why Fastly's involved. Thanks!
| peteretep wrote:
| > you cannot express anything malicious in Wasm
|
| This feels like a comment that will as age as badly as "you can't
| get a virus just from looking at an email"
| jedisct1 wrote:
| You can't express anything malicious in JavaScript either, yet
| vulnerabilities are constantly found in web browsers, including
| WebAssembly JITs.
|
| You can express malicious things in Go, yet the number of RCEs
| in Go apps is pretty much zero.
| amelius wrote:
| > You can't express anything malicious in JavaScript either
|
| You have to be more specific because lots of fraud is
| possible by misleading the user through JavaScript tricks.
| CyberRabbi wrote:
| Full device root from JavaScript
| https://github.com/synacktiv/PS4-webkit-exploit-6.XX
| alquemist wrote:
| That's a bit of apples and oranges. JS/WASM are runtimes
| executing hostile code, whereas Go apps are trusted code.
| etimberg wrote:
| What about something like https://github.com/IAIK/rowhammerjs
| ?
| mhh__ wrote:
| Depends - eBPF is statically verified pretty well, but spectre
| (and all its brothers) is a cruel mistress
| bagels wrote:
| Sounds like the promises made about the jvm.
| nih0 wrote:
| can u elaborate on these jvm promises?
| officialchicken wrote:
| The "sandbox" promise was/is still offered as the primary
| line of defense for Java.
|
| "The first version of Java was released by Sun Microsystems
| in 1995 [2]. One year later, researchers at Princeton
| University identified multiple flaws enabling an analyst to
| bypass the sandbox [3]. The authors identified weaknesses
| in the language, bytecode and object initialization, to
| name a few, some of them still present in Java at the time
| of writing."[0]
|
| [0] https://www.exploit-db.com/papers/45517
|
| [2] http://www.oracle.com/technetwork/java/javase/overview
|
| [3] Drew Dean, Edward W. Felten, Dan S. Wallach. "Java
| security: From HotJava to Netscape and beyond." In Security
| & Privacy, IEEE, 1996
| marcosdumay wrote:
| The Java sandbox trusted any code signed with a SSL
| certificate by design, what didn't stop Sun from
| announcing it was secure and everything.
| colesantiago wrote:
| What does this mean for Shopify merchants? Is it all just faster
| apps?
|
| I'm still at a loss that Shopify still does not have a
| subscriptions product. :/
| sradman wrote:
| The article ends with:
|
| > As we tear down the boundaries between Partners and
| Merchants, we connect merchants with the entrepreneurs ready to
| solve their problems.
|
| "Partners" are a key part here, I think. Merchants can run
| their own code or possibly install 3rd party partner plugins.
| This is similar to the way 3rd party Wordpress Plugins work
| except, unlike PHP, they are small, fast, and safe. They can
| also run in a multi-tenant Shopify environment that scales
| safely.
|
| As far as I can tell, the use case is similar to database
| triggers or custom web request filters: enhance the standard
| request flow with custom actions.
| SingAlong wrote:
| They do allow merchants to sell subscriptions -
| https://help.shopify.com/en/manual/products/subscriptions
| rattray wrote:
| I think this is super new - there are only two apps that
| offer subscriptions that integrate with Shopify Checkout, and
| one of them launched in November it seems and is still in
| beta:
|
| https://apps.shopify.com/collections/checkout-subscription
| TheGeminon wrote:
| Yes, I work at Shopify and our first party subscription
| support just recently launched a few months ago.
| rattray wrote:
| Awesome! Very exciting. I recently launched a small
| business which has a natural subscriptions element
| (https://narwallmask.com - a mask with replacement
| filters, which you may want regularly) but without subs
| integrated into shopify checkout, I decided simply not to
| offer it. Maybe now I can!
|
| Can you say whether wasm helped make this happen? Seems
| quite plausible to me...
| ewalk153 wrote:
| Perhaps in the future (on the team that added
| subscriptions at Shopify)
| xg15 wrote:
| Pro: You don't need server infrastructure to customise a
| Shopify flow.
|
| Con: You need coders knowledgeable in WASM.
|
| However, I could imagine that an ecosystem of "plugins" could
| emerge, i.e. ready-made WASM apps that merchants could plug
| into their stores.
|
| There might be more security issues though, if the developer of
| the WASM and the merchant using it aren't the same party. I
| think it will be interesting to see how this will play out.
|
| Then again, it might be sufficient to to code something in an
| LLVM-supported language of choice, then compile it to WASM and
| just hook it into Shopify, without needing to understand the
| WASM code that was generated. Good luck troubleshooting or
| debugging this though...
| gfxgirl wrote:
| Why do you need coders knowledgeable in WASM? The majority of
| coders will use something else (C, C++, Rust, C#, etc.) The
| majority of them don't need to know the details of the
| processor their compiler is targeting.
| xg15 wrote:
| You're right, but I think nonexistent monitoring/debug
| capabilities are still a problem. For JS, if something goes
| wrong, you have a vast array of tools available to
| troubleshoot the problem. The amount of tools for WASM in
| the browser are smaller, but at least the code runs in an
| environment you know and can control. With the WASM plugin
| approach presented here, you're dependant on the tools the
| host service (in this case Shopify) provides. There is
| probably not much hope that they will offer step-through
| debugging or stack traces in the language the code was
| originally written, so being able to understand the actual
| WASM might become more important.
|
| There might also be the point of APIs. I'm no expert, but I
| imagine in-browser WASM must have access to some set of
| browser-specific APIs to communicate with JS and the DOM.
| Shopify won't have those APIs available in its runtime
| environment, but will probably offer different APIs to
| communicate with the purchase flow etc. I don't know how
| the WASM tooling landscape looks, but if most tools assume
| the browser APIs to be available, this could make it harder
| to develop WASM for other contexts. E.g., you can compile
| Unity games to WASM, but that WASM will assume that it runs
| in a browser. You probably couldn't use Unity to write a
| Shopify plugin.
| marcosdumay wrote:
| At the moment, knowing how to compile X to WASM and have it
| run is a kind of expertise.
|
| I hope that changes, the sooner the better, but right now
| it's not trivial.
| gfxgirl wrote:
| The Blazor tutorials just run (C#). It is trivial
|
| Same with Unity. Click build. Trivial
|
| I suspect others are similarly trivial
| pangoraw wrote:
| I think it is why they have gone with AssemblyScript as the
| main supported language. Since it is similar to Typescript,
| Web developers will likely have a easier time learning it.
| [deleted]
| azangru wrote:
| The article starts with "what is webassembly", but doesn't
| breathe the keyword WASI [0], although they are using a service
| that's implementing it?
|
| [0] https://hacks.mozilla.org/2019/03/standardizing-wasi-a-
| webas...
| lsaferite wrote:
| The linked page on Lucet does call out WASI if that make it any
| better.
| CyberRabbi wrote:
| Technically you can accomplish the same thing using seccomp, I.e.
| the way most services run third party native code to process
| untrusted data, e.g. imagemagick.
|
| That's what I would probably do since it's more efficient and
| simpler. No need for a compilation step or an interpreter. No
| need to trust the (likely complex) webassembly runtime to be bug
| free.
|
| Edit: most responses are being made under the assumption that
| seccomp is the same as seccomp-bpf. The two are different and
| designed for different use cases. For example it is not possible
| to run a wasm JIT entirely under seccomp but is possible under
| seccomp-bpf. Seccomp was specifically designed for the use case
| described in this article by Shopify. You can read more about the
| differences here https://en.wikipedia.org/wiki/Seccomp
| xg15 wrote:
| I think WASM has the added benefit of being platform-
| independent - which is generally a good thing but can even be a
| security feature: With native code, even if run without
| privileges, you need to expose a lot of details about your
| hardware that malicious users could use to find
| vulnerabilities.
|
| With WASM, the host can keep the actual hardware architecture
| and even the actual machine code that is generated a secret.
| CyberRabbi wrote:
| Yeah but there's a nearly 100% chance your server platform is
| x86 and in the case that it changes, it will be a gradual
| change in the long term.
|
| While it's nice to have the platform independence, it has
| nearly zero practical utility here.
|
| If you're making a security argument, using seccomp over a
| complex webassembly runtime reduces your attack surface.
| croes wrote:
| Security by obscurity?
| feanaro wrote:
| Shopify is already a known seccomp user (for running Ruby in
| the mruby VM), so I think there's no reason to assume the
| WebAssembly runtime is not in a seccomp jail too.
| CyberRabbi wrote:
| That's just redundant
| emteycz wrote:
| Exactly, and there is probably a third redundancy too.
| eloff wrote:
| I don't think you get security. It's about threat
| mitigation. There is nothing secure, including seccomp
| jails.
|
| You want defence in depth - that is using multiple layers
| of defence to reduce the risk. You can never get it to 0,
| but if you combine two mechanisms that are each 99%
| effective, then your risk is now 0.01% instead of 1%.
| That's obviously an improvement.
|
| You don't run your database without a password (hopefully)
| just because its behind a firewall. You want to have the
| password as well in case an attacker finds a way around
| your firewall (compromises a system on the inside) or you
| misconfigure your firewall.
|
| Security in the physical world works the same way. You
| don't turn off the alarm and leave the bank doors open at
| the end of the day just because your vault is quite secure.
| CyberRabbi wrote:
| I don't think you get the difference between seccomp and
| seccomp-bpf
| eloff wrote:
| You've been downvoted to oblivion. Don't you think that's
| a sign that maybe you're wrong?
| garethrowlands wrote:
| Redundancy is sometimes good. When it comes to containing
| exploits, surely it's better to be safe than sorry.
| the_mitsuhiko wrote:
| There is a big difference between running "third party native
| code" that you have some level of trust of (eg: image magick)
| vs having customers upload code to your infrastructure.
|
| In the latter case I'm not aware of a single service that uses
| seccomp to do this. The closest to a non WASM setup is either
| things like Firecracker or to enforce some sense of sandboxed
| language like JavaScript. Seccomp quite often plays a role in
| keeping those sandboxes safe, but it's generally not used to
| have people execute arbitrary binary blobs on SaaS.
|
| Having people compile code to WASM to execute it in a sandbox
| is becoming quite widespread. Shopify is not the first company
| to do that.
| CyberRabbi wrote:
| > Having people compile code to WASM to execute it in a
| sandbox is becoming quite widespread. Shopify is not the
| first company to do that.
|
| Whether or not a technical solution is good is not dependent
| on it being employed by other companies. Using seccomp to run
| untrusted code is a better solution than wasm because it's
| less code and more efficient.
| the_mitsuhiko wrote:
| > Whether or not a technical solution is good is not
| dependent on it being employed by other companies
|
| You said it's state of the art and simpler as WASM. I'm not
| actually aware of a single company using seccomp for what
| Shopify is doing (letting people upload custom code) so I
| would be quite curious to hear who does.
| CyberRabbi wrote:
| I never said anything was "state of the art" or made any
| claim that any company is using seccomp to accomplish
| what Shopify is doing.
|
| I said that companies typically run third party native
| code, e.g. imagemagick, in seccomp to process untrusted
| data, e.g. user-uploaded image files.
|
| If I were tasked with doing what Shopify is doing with
| wasm here, I would employ the seccomp-based solution
| since it's equally applicable, it requires less code, and
| it's more efficient. Whether or not other companies use a
| seccomp solution for this particular use case has no
| technical basis in determining its applicability for this
| use case. Seccomp was specifically designed for running
| untrusted code on your infrastructure, this exact use
| case.
| tpetry wrote:
| And i would run wasm with a seccomp profile: You have the
| benefit of language designed which is hard to not do
| anything malicious (i guess theres still some
| possibility) and harden the execution environment (wasm
| runner) within a rootless pofman/docker container with a
| seccomp profile and restrictive selinux labels.
|
| The world is not black and white, you can mix multiple
| solutions for more security. For what shopify is doing
| you need the most security you can get. Your example
| running a trusted application (imagemagick) with
| untrusted input is a lot easier to make secure than
| running untrusted binaries.
| CyberRabbi wrote:
| Using wasm in addition to seccomp-bpf (what you're
| calling seccomp) strictly increases your attack surface.
| If you want to maximize security you would only use
| seccomp.
|
| Imagemagick is not trusted to process arbitrary data,
| otherwise there would be no need to use seccomp. Seccomp
| was specifically designed for running untrusted binaries.
| Check references if you do not believe me:
| https://en.wikipedia.org/wiki/Seccomp#History
| feanaro wrote:
| > Using wasm in addition to seccomp strictly increases
| your attack surface. If you want to maximize security you
| would only use seccomp.
|
| Huh? How so?
| CyberRabbi wrote:
| The wasm vm has to parse, validate, and compile untrusted
| input. It also exposes host calls. Those are all
| potential attack vectors. That's at least roughly 50K
| LOC.
| imtringued wrote:
| >It also exposes host calls.
|
| Only if you grant explicit access to them. What usually
| happens is that there is a vendor provided API that only
| gives you access to exactly what you need which is
| significantly less powerful than a complete linux process
| that can write to files, spawn background threads, etc
| all by default.
|
| Yes you can block access to these things but you're going
| to miss something at some point.
| alquemist wrote:
| In a WASM + seccomp implementation, the whole WASM
| runtime runs inside seccomp. Breaking out of WASM leaves
| one running arbitrary asm inside seccomp, which has
| exactly the same attack surface as directly running
| untrusted binaries inside seccomp. The WASM layer in WASM
| + seccomp simply requires an additional exploit.
| CyberRabbi wrote:
| You're referring to seccomp-bpf, not seccomp. Seccomp-bpf
| + wasm has a dramatically larger attack surface than just
| seccomp. Please check references if you do not know the
| difference between seccomp-bpf and seccomp:
| https://en.wikipedia.org/wiki/Seccomp
| devwastaken wrote:
| That's a pretty bold statement. I'd like to see an in depth
| analysis between the two before supporting that.
| CyberRabbi wrote:
| It's readily apparent:
|
| More efficient: using wasm has a necessary compilation or
| interpretation overheard. Seccomp doesn't.
|
| Simpler: wasm requires deploying running an entire wasm
| runtime, likely >= 50K LOC in additional complexity and
| attack surface. Seccomp uses a small 100 line shim.
| imtringued wrote:
| You can run WASM to grant fine grained access to certain
| APIs. You might be able to do this with a sidecar that
| provides the API over HTTP and then let the untrusted
| process only access the side car but why do this when you
| can just grant API access to a WASM module? From the
| perspective of the third party user the API can be called
| directly via a function instead of doing a HTTP request.
| alquemist wrote:
| It's not an either/or. Most likely Shopify runs WASM inside an
| seccomp enclosure. Possibly inside a VM as well. Defense in
| depth.
| CyberRabbi wrote:
| Running untrusted code in a wasm vm doesn't add any extra
| defense over just using seccomp. It just adds unnecessary
| overhead and increases attack surface.
| alquemist wrote:
| Assuming that Intel / ARM microarch implementations are bug
| free, that is correct. In the real world there are no bug
| free implementations.
|
| Edit. This is the strategy Chrome sandboxing uses: a
| hardened runtime (JS/WASM) inside a seccomp enclosure. http
| s://chromium.googlesource.com/chromiumos/docs/+/master/s...
| CyberRabbi wrote:
| Running code in a wasm vm doesn't magically prevent user
| code from exploiting uarch bugs. Lucet specifically does
| not mitigate spectre variant 2.
| feanaro wrote:
| seccomp escapes are a thing and if you're inside a
| restrictive environment such as WASM, it is harder to
| achieve it.
| CyberRabbi wrote:
| I think you're referring to seccomp-bpf. seccomp has
| never been escaped and it is unlikely such a bug could
| happen due its simplicity. If you do not know the
| difference between seccomp and seccomp-bpf, please check
| references: https://en.wikipedia.org/wiki/Seccomp
| tuwtuwtuwtuw wrote:
| Unlikely? Sounds like you think it could happen.
| CyberRabbi wrote:
| Nothing is 100%. It's effectively impossible.
| bobthebuilders wrote:
| This disproves your point. How many "effectively
| impossible" exploits have come out recently?
___________________________________________________________________
(page generated 2020-12-19 23:00 UTC)