cli VS notes

Co-funder @ Phylum here (https://phylum.io) We have been actively scanning dependencies across npm (and PyPI, RubyGems, Crates.io, etc.) for nearly three years now; quite successfully, I might add (https://blog.phylum.io/tag/research/). We _automatically_ hit on this package when it was published, and our research team has been all over it.

A collective of us are active in Discord (https://discord.gg/Fe6pr5eW6p), continuing to hunt attacks like these. If that's something that interests you, we'd love to have you!

In addition to this, we've released several open source tools to help protect against supply chain attacks:

1. https://github.com/phylum-dev/birdcage - Birdcage is a cross-platform embeddable sandbox that's been baked into our CLI (which wraps npm, pypi, etc.) to sandbox package installations

2. https://github.com/phylum-dev/cli - Our CLI provides an extension capability so you can lock down random executables you might use during your software development (define _what_ it's allowed to do, e.g. network access, and then lock it down with Birdcage)

We also have a variety of integrations, including Github, Gitlab, BitBucket, CircleCI, Tines, Sophos, etc.

https://docs.phylum.io/docs/integrations_overview

It's unfortunate that software dependency attacks continue to plague open source registries. It seems unlikely this will let up in the near future. We are continuing to work closely with the open source ecosystems to try and get these sorts of packages removed when they pop up.

We're actively working on this with our sandbox (https://github.com/phylum-dev/birdcage). We've wrapped the likes of pip, yarn, and npm already and are making moves to similarly provide support for cargo.

Currently comes as part of the Phylum CLI (https://github.com/phylum-dev/cli), so that doing something like:

    phylum npm install 

cli - uses sandbox to block packages during installation, performs pre-install checks to determine (by hitting the API) if the package performs actions congruent with malware, e.g. phylum pip install requests will use pip wrapped by the sandbox to install requests after verifying that it doesn't have malware like behavior.

This is bundled with our CLI tool today (which is also open source) and allows you to install packages with phylum npm install . We currently support npm, yarn and pip and are planning on rolling out further support for other ecosystems in coming months.

We open sourced our tooling to help with this problem specifically. We have an extension framework that wraps npm for three purposes:

Our CLI tool (also open source and free) will check for typosquats, dependency confusion, malicious code, vulnerabilities, etc. in your package dependencies. Works for pypi, npm, rubygems, maven, nuget and very recently golang and rust crates.

This is built into the Phylum CLI so you can do things like:

This is one of the projects we're working on (and open sourcing)!

Currently allows you to specify allowed resources during the package installation in a way very similar to what you've outlined [1].

The sandbox itself lives here [2] and can be integrated into other projects.

1. https://github.com/phylum-dev/cli/blob/main/extensions/npm/P...

2. https://github.com/phylum-dev/birdcage

We will start here with a slightly more in-depth, custom version of the existing NPM shim extension - a tool that enforces default project policy when installing NPM packages. This custom extension will do some additional custom validation before allowing the installation process to continue.

It's (partially) a fundamental problem with Python and most other programming languages. The majority of libraries don't need more authority than doing (some) computation, yet any Python script can access anything and everything by default.

https://en.wikipedia.org/wiki/Capability-based_security is the solution for this, yet Python will probably never be capable of this kind of internal encapsulation, it's too much of a fundamental change - and even if some sort of sandboxing ability is accomplished, creating separate/recursive sandboxes (needed when importing more, separate libraries) will probably require another interpreter instance (as with WebAssembly).

I hope current and future language designers will take this into account, and construct their compilers, virtual machines and interpreters accordingly. Python was created before the internet as we know it now existed, so perhaps its lack of security mechanisms shouldn't be surprising. But it and any new developments that fail to consider this aspect of computation will be fundamentally flawed from the beginning.

https://github.com/void4/notes/issues/41

Not if done correctly. Have a look at this link: https://github.com/void4/notes/issues/41

There is no issue with just limiting resources (unless there is unpredictable overhead). It doesn't have to be hardware resources either, it could be abstract/higher level resources like interpreter steps or managed memory slices.

I'm creating a series of VMs to show that this is possible, like rarVM, the recursively sandboxable virtual machine: https://esolangs.org/wiki/RarVM

Showcase: https://www.youtube.com/watch?v=MBymOp6bTII

When calling a function you can specify how many interpreter steps it can run until it aborts (and optionally gives you a continuation so you can "refill" and resume it later).

Stackless Python can do this too, but unfortunately due to the reasons discussed above will never be a safe language, this specific mechanism works only in trusted environments since the called function has the ambient authority to increase its own resource limits: https://stackless.readthedocs.io/en/2.7-slp/library/stackles...

Another approach would be to have a counter (or several) that limit the number of instruction steps, like the Stackless Python programming language (https://stackless.readthedocs.io/en/latest/library/stackless...) or the KeyKOS operating system (https://github.com/void4/notes/issues/41) did

Ann Hardy programmed one of the first mainframe operating systems, and certainly the most secure one: KeyKOS

There are syntactic and semantic aspects. Personally, I think algebraic effect systems and capability security seem to be very worthwhile areas of research because they provide abilities and guarantees that just aren't possible with currently popular languages due to their architecture.

This might be of interest to you: "Why KeyKOS is fascinating" - https://github.com/void4/notes/issues/41