21–30 of 31 posts
I'm glad this is beginning to be taken seriously. And that the answer isn't "sandbox every dependency" which is ridiculous.
Don't miss how we used TUF [1] and in-toto [2] to build compromise-resilient CI/CD (the first in the industry AFAICT) for the Datadog Agent integrations [3][4] that detects attacks anywhere between our developers and end-users [1] https://theupdateframework.io/ [2] https://in-toto.io/ [3] https://www.youtube.com/watch?v=9hCiHr1f0zM [4] https://dtdg.co/integrations-tuf-in-toto
How this pattern/toolset protect against supply chain compromises of the dependencies used to build the "Datadog Agent" itself?
Earlier quoted context omitted.
How this compares with https://github.com/theupdateframework/notary ?
Notary is a signing scheme from the publisher. It is an improvement over GPG signing + a better scheme for signaling to clients the next version to update. Asset Transparency doesn't require the publisher to be involved at all and can work on any URL on the internet that is publicly accessible. It also complementary to signing schemes. Here is the Asset Transparency CLI fetching and verifying the contents of a notary…
https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...
And more reading on this matter, relevant to CCleaner's supply chain mishap: https://www.wired.com/story/inside-the-unnerving-supply-chai... Something like Bleachbit seems more reputable, but not necessarily immune from similar attacks, but it's what I use instead of CCleaner.
I'm glad this is beginning to be taken seriously. And that the answer isn't "sandbox every dependency" which is ridiculous.
Why is that ridiculous? Certainly it’s not the sole answer to the problem on its own, but if I were to use (say) a string manipulation library, why should it have access to my filesystem and the internet?
You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities. And it doesn't even guarantee that the code doesn't do other bad things that the sandbox doesn't deny. Sandboxing has comprehensively failed as a security measure for browser extensions - hence both Chrome and Firefox retreating from extensions.
Or, as a spurious example: you could audit the library's code to make sure it's not doing bad things, and then copy/paste it into your code base. You could even just copy the bits you need and leave the bits that deal with use cases that you don't need. Easier, simpler, more efficient and less dangerous.
And more reading on this matter, relevant to CCleaner's supply chain mishap: https://www.wired.com/story/inside-the-unnerving-supply-chai... Something like Bleachbit seems more reputable, but not necessarily immune from similar attacks, but it's what I use instead of CCleaner.
Earlier quoted context omitted.
How this pattern/toolset protect against supply chain compromises of the dependencies used to build the "Datadog Agent" itself?
Apply pattern/toolset recursively. Software supply chain problems largely eventually solved this way.
Earlier quoted context omitted.
Why is that ridiculous? Certainly it’s not the sole answer to the problem on its own, but if I were to use (say) a string manipulation library, why should it have access to my filesystem and the internet?
Because it's not an app. It's just some code. You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities. And it doesn't even guarantee that the code doesn't do other bad things that the sandbox doesn't deny. Sandboxing has comprehensively faile…
Yes. So?
>You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities.
I'm going to dispute this. Yes, if your sandbox takes a ton of memory to isolate some piece of code, scaling that up to confine each module individually isn't going to be workable. But who says a sandbox has to be heavyweight?
Our current systems (UNIX-likes, etc) provide a ton of ambient authority to each process; given that, it takes a lot of effort to e.g. intercept syscalls and decide whether or not the application should have access to them. That's an artifact of design decisions from decades ago, though; let's say we were starting from scratch, why give every process access to all those syscalls to begin with? If you want an example of how a system could be designed from the start without that authority, take a look at this paper: http://mumble.net/~jar/pubs/secureos/secureos.html
For a recent attempt at doing essentially this, take a look at this intro to the Bytecode Alliance: https://hacks.mozilla.org/2019/11/announcing-the-bytecode-al...
Earlier quoted context omitted.
Because it's not an app. It's just some code. You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities. And it doesn't even guarantee that the code doesn't do other bad things that the sandbox doesn't deny. Sandboxing has comprehensively faile…
>Because it's not an app. It's just some code. Yes. So? >You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities. I'm going to dispute this. Yes, if your sandbox takes a ton of memory to isolate some piece of code, scaling that up to confine…
There's a difference between compiled binary and uncompiled code. I guess if you're working in an interpreted language that never gets compiled, like Python, you might not notice the difference so much. But even then, this is not using an API for a separate service that exists on a different server. This is something that happens in your process.
> ...processes...
If your string processing library has to live in a separate process in order to sandbox it, then yes, you are creating more problems than you're solving.
Earlier quoted context omitted.
A toolset that answers some of your questions is grafeas- a metadata store at https://github.com/grafeas/grafeas- and kritis, a policy engine at https://github.com/grafeas/kritis . Cheers.
Thanks for the links. Do you know how this toolset helps to mitigate/prevent what is called in the GitHub blogpost "Supply chain compromises". Quickly checked around and couldn't find anything that applies to the dependencies of applications/binaries before they land into the target runtime (i.e k8s).
https://www.slideshare.net/mobile/aysylu/q-con-sp-software-s....
They walk through one of the workflows (end state is deploying to k8s).
Grafeas is a metadata store, Kritis is a policy engine that plugs into k8s as an admission controller- blessing the "admission" (running) of an image in a namespace.
There are existing tools for each language/runtime that produce known vuln lists for individual artifacts in the language ecosystem. These you feed into Grafeas. And you have your CI pipeline providing manifests for each of your built images that contain all upstream dependencies (these produced from each app's build tool). Then at deploy time, Kritis checks the manifest on the image, and for each artifact in the image, checks for vulns and determines whether the vuln should keep the image from being deployed.
Hope that helps. There are many other workflows but that one is the most direct.
Cheers.