181–190 of 334 posts
I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…
Open/free software is great when a great person writes some code and lets you use it, because they are kind and there's nearly no marginal cost. But malicious actors can get value from polluting the sharing network, and that costs effort to defend against, which means someone(s) has to pay to secure the network, or be open to attack.
That’s not an either or thing. Someone you pay to can also be a malicious actor.
I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…
1. `autobox` (to be renamed lol) [0]. It's basically a Rust interpreter that performs taint and effect analysis, reporting on both, allowing you to use that information to generate sandboxes. ie: "autobox sees you used the string '~/.config' to read a file, and that is all the IO performed, so that is all the IO you get".
2. I'm working on a container based `cargo` with `riff` built in that aims to work for the vast majority of projects and sandbox your build with a defined threat model.
The goal is to be able to basically `alias cargo=cargo-sandboxed` and have the same experience but with a restricted container environment + better auditing of things happening in the container.
3. I previously built a POC of a `Sandbox.toml` and `Sandbox.lock` with a policy language that allowed you to specify a policy for a given build step. Unfortunately, I couldn't decide on how I wanted it to work in terms of "do I generate a single sandbox for the entire build, or do I run each build stage in its own sandbox" - there are tradeoffs for both.
Here's a lil snippet:
[build-permissions.file-system]
// All paths are relative to the project directory unless they start with `/`
"../" = {permissions = ["read"]}
// "$target" being a special path
"$target" = {permissions = ["read", "write"]}
// Source this path from the environment at build time, `optional` means it's
// ok if it isn't available
"$env::PROTOC_PATH" = {permissions = ["read", "execute"], optional=true}
// Default protobuf installation paths, via regex
"^(/usr)?/bin/protoc" = {permissions = ["read", "execute"], regex=true}
`autobox` is fun but I think it may be impractical without more language level support and no matter what I'd end up having to implement it in the compiler at some point, which means it would be unusable without nightly or a fork.
I'm going to try to wrap up an autobox POC that handles branching and loops, publish it, and see if someone who does more compilery things is willing to pick it up. As for (2) and (3) I believe I can build practical implementations for both.
Earlier quoted context omitted.
In Python, dynamic imports exist, making this impossible
I don't see how having dynamic imports matters if all you want to do is detect if a specific file is imported. Run the install and see what gets imported. That's it.
I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…
I thought that Java Applets (and maybe flash, I am less familiar) had an advanced security model, but it was exploit after exploit because of the huge attack surfaces? I suspect you may run into similar sandbox escapes once things are complicated enough. So it seems like a good idea if they can be made bug free, but good luck with that?
The certificate could contain information about the owner and the consumer could check if he wants to deal with the owner or not. Developers could add a desired whitelist to pip (or use a curated one) to continue using automation.
I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…
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
I think a proper way to solve this issue, not specific to python but languages running in a VM in general, would be to have some sort of language support where you specifically define what access rights/ system resources you allow for any given dependency. Example of defining project dependencies: { "apollo-client": { "version": "...", "access": ["fetch"] // only fetch allowed }, "stringutils": { "version": "...", "a…
I've been messing around with some ideas. 1. `autobox` (to be renamed lol) [0]. It's basically a Rust interpreter that performs taint and effect analysis, reporting on both, allowing you to use that information to generate sandboxes. ie: "autobox sees you used the string '~/.config' to read a file, and that is all the IO performed, so that is all the IO you get". 2. I'm working on a container based `cargo` with `riff…
I wonder why we can’t have pip packages be published by username or organization, like pip install google/tensorflow It would significantly reduce the attack space
It gives false sense of security. What about google_official/tensorflow
not perfect, but better.
Earlier quoted context omitted.
I've been messing around with some ideas. 1. `autobox` (to be renamed lol) [0]. It's basically a Rust interpreter that performs taint and effect analysis, reporting on both, allowing you to use that information to generate sandboxes. ie: "autobox sees you used the string '~/.config' to read a file, and that is all the IO performed, so that is all the IO you get". 2. I'm working on a container based `cargo` with `riff…
This is really cool work! Also a fan of Grapl.