Backdoor discovered in Ruby "strong password" library, takes your "strong passwords" and uploads them into a pastebin

Hi, do you believe me when I say we need ocap security yet

@cwebber how would an OCAP scheme solve the problem of a compromised third-party library loading arbitrary code from an attacker-controlled pastebin?

serious question

@VyrCossont @cwebber I think the point is that code is internally limited so different libraries can't access data or services they're not supposed to?

So in this case, the library can't exfiltrate data because it can't network.

@astraluma @cwebber one could also say the same about other sandboxing mechanisms for third-party code, so i was wondering what the particular OCAP advantage, if any, would be here

@VyrCossont @astraluma Ocaps can be seen as a sandboxing mechanism, but rather a paradigm where everything is sandboxed and yet it isn't hell because it resembles the way we pass around arguments in our programs. One advantage that ocaps have over contemporary sandboxes is that they can acquire just-in-time authority also. But that sounds like nonsense without further explaination, which I will have to do at a future time.

I should probably blog explaining this stuff a bit more clearly :)

@VyrCossont @astraluma Here's an example of what I mean by just-in-time-authority. Here are two worlds:

- One where we list what documents you can access up-front. Now you can't access anything you shouldn't be able to, but you can't access *new* documents.
- One where you start with a set of documents you can access, but as the world moves and changes, we can also pass you access to new documents

Imagine the fediverse built with the former. You could never gain new friends!

@VyrCossont @astraluma This is why the just-in-time acquirement of authority in ocaps is really key: in the fixed-set-of-authority model, it's so annoying and rigid that eventually you'd pass in way more authority than you need, rather than being able to acquire the authority you need when you need it.

@cwebber @astraluma no, that part makes perfect sense, especially given the current "full network access or nothing" choice that many app store sandboxes still have

so you might build a capability-based Mastodon server with an HTTPS capability manager that has its own capabilities:
• make an HTTPS connection to a domain on the safelist
• request safelisting a new domain…
@cwebber @astraluma

the part of your server that handles auth should never be able to request new domains on its own, so you'd give it a diluted capability with only the first one

and it'd never give either to the password library…
@astraluma @cwebber this really doesn't really do much for the transitive trust problem for third-party code

maybe your runtime and package manager is extended to specify additional restrictions on capability propagation between dependencies and transitive dependencies

honestly, it's about time
@astraluma @cwebber but this level of capability-based design would require a fairly massive restructuring of any application that wanted to use it, as well as a language, runtime, and standard libraries that (a) supported capabilities and (b) was totally free of trapdoors into lower-level operations.

which is the real problem. there may be research languages that can do this, but is anyone shipping code in them today? or even close?

@VyrCossont @astraluma We can constrain as much as we can (for mastodon, the whole program), but for new programs, we can get this level of security

@cwebber @VyrCossont @astraluma Some might see this as a disadvantage, but the advantage of OCAP comes explicitly *from* the API rework that will be required to adopt it. Since ocaps are (as a first-order approximation and most programmers' perspective) typed opaque values used as pointers or handles typically passed by value to dependencies that use them, it makes explicit a lot of security-related state which is currently implicit in trusted code bases that really ought not be trusted.

@cwebber @VyrCossont @astraluma Just as NULL-free coding requires changes to code in exchange for more reliable software, so too would adoption of OCAP-style API designs. It's painful, but it'll be very much worth it.

@vertigo @astraluma @cwebber agreed, but, like, let's say i'm writing a new fediverse server today

y'all are telling me to make that thing OCAPpy

where do i start

@VyrCossont @cwebber @astraluma Good questions; I'd like to know that myself. From my limited understanding, unfortunately, I think it has to start with the host OS's most basic APIs. Without kernel support, there'll always be a confused deputy waiting to accidentally obey orders from malicious code.

@vertigo @astraluma @cwebber yeah so that's not going to happen. period. i don't make apple pie starting with the universe, i don't have the budget…
@vertigo @astraluma @cwebber with current tech and a language targeting native code, you could do something like shatter your app into hundreds of processes to isolate dependencies and important internal components, communicating thru IPC, each running in a possibly-ephemeral sandbox with permissions set by the parent process

think actor system + SELinux

it'd be an absolute nightmare to write and debug, and probably run like shit

@VyrCossont @cwebber @vertigo Sounds like local SOA? It could be doable with at least high-level components.

But yeah, if you wanted to do this for every actor in your code, that would be thousands (millions?) of processes and would perform like crap.

Sign in to participate in the conversation

cybrespace: the social hub of the information superhighway jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal support us on patreon or liberapay!