proj-oot-ootCapabilitiesNotes2

this discussion shows that there used to be something called "MPX" but it was bad, so don't learn from MPX:

https://lobste.rs/s/qqlz5l/so_i_ve_patched_kde_plasma_wayland_under

---

DonbunEf?7 on May 23, 2017

parent context prev next [–]on: Viper: a new programming language from Ethereum

Stop. Read http://www.erights.org/talks/promises/paper/tgc05.pdf. Then start again.

jpolitz on May 23, 2017

parent next [–]

Is there a particular piece of insight from that paper that indicates a mistake in the design of Viper? I love erights' work and don't doubt that there is a lot to be learned from it in this context, but some guidance on how to apply it here would help.

DonbunEf?7 on May 23, 2017

root parent next [–]

The DAO attack was plan interference. Absorb and grok that idea, and then the rest will hopefully follow.

Specifically, Viper has two glaring flaws, both of which are not suffered by E, Monte, etc. The first is a lack of correct encapsulation. Viper appears to have a Python-style object model, which means that it's not possible to closely hold a value. As a test, how would you build an object with a value in its closure which no other object can access?

Second, Viper doesn't have mitigation for plan interference, which means that it's possible for certain kinds of recurrences to alter your program's security guarantees. As a test, how would you mitigate the DAO attack in Viper?

Finally, I fear that these flaws may be inherent to Ethereum, meaning that any language on Ethereum inherits these flaws structurally and cannot mitigate them. In that case, maybe it's time to design a capability-safe Ethereum!

abecedarius on May 23, 2017

root parent next [–]

Indeed, in the (pre-DAO) Ethereum audit report https://github.com/LeastAuthority/ethereum-analyses/blob/mas... they brought up your second issue and recommended Mark Miller's thesis (which covers the material in the OP).

I haven't looked into Viper and how it might address these matters.

---

DonbunEf?7 on May 2, 2017

parent context prev next [–]on: Cap'n Proto 0.6 released – 2.5 years of improvemen...

As usual, nobody has said "capability" yet, which is unfortunate, because one of Capn's biggest strengths is that it embodies the object-capability model and is cap-safe as a result.

Edit: Why does this matter? Well, first, it matters because so little software is capability-safe. Capn's RPC subsystem is based directly upon E's CapTP? protocol. (E is the classic capability-safe language.) As a result, the security guarantees afforded by cap-safe construction are extended across the wire to cover the entire distributed system. This security guarantee holds even if not every component of individual nodes is cap-safe, and that's how Sandstorm works.

Continuing on, there's also historical stuff going on. HN loves JSON; JSON is based on E's DataL? mini-language for data serialization. HN loves ECMAScript; ES's technical committee is steered by ex-E language designers who have been porting features from E into ES.

kentonv on May 2, 2017

parent next [–]

The trouble is, we capability people have come up with our own language full of jargon that no one else knows, and I think it confuses people. When talking to people new to the idea, I try to use the term "object reference" or maybe "endpoint reference" rather than "capability", to be more approachable.

---

erustemi 10 hours ago

next [–]

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": "...",
       "access": [] // no system resources allowed for this dependency, own or transitive
    },
    ...
  }

It would probably require the language to limit monkey-patching core primitives (such as Object.prototype in javascript), and it would be more cumbersome for the developer to define the permissions it gives to each dependency. These required permissions could be listed on the package site (eg npm or PyPI?) and the developer would just copy paste the permissions when adding the dependency. But if you upgrade a dependency version and it now requires a permission that seems suspicious (eg "stringutils" needing "filesystem"), it would prompt the developer to stop and investigate, or if it seems justified add the permission to "access" list.

reply

c0balt 10 hours ago

parent next [–]

At the beginning the permissions aspect of deno[0] was actually on of the major selling points for me. The approach used there was to begin at zero and offer granular permission control, e.g. `--allow-read=data.csv`, for filesystem, network etc. I would love to have this for, e.g., python or npm packages.

[0]: https://deno.land/manual@v1.27.0/getting_started/permissions

reply

jens0 10 hours ago

root parent next [–]

Doesn't this only apply to the entire process? Not the individual dependencies, right? Just confirming, Deno was my first thought with this, it requires the developer to deliberately enable permissions needed.

reply

SahAssar? 9 hours ago

root parent next [–]

Yes, it applies to the whole process. It's incredibly hard to sandbox dependencies individually since you don't know how your code or other dependencies interact with it. If you want you can run dependencies in a worker process and sandbox that tighter, but that is quite a bit of work.

reply

juancampa 6 hours ago

root parent next [–]

This is exactly what I've done for Membrane[0]. It's capabilities based, even to get the time (and thus introduce non-determinism) you need a capability. Dependencies run as separate processes and everything is orthogonally persistent. It's a typescript/javascript system for personal automation built entirely within VSCode. Stay tuned, I'll be posting a video this week.

[0] https://membrane.io

reply

ashishbijlani 8 hours ago

root parent prev next [–]

That’s exactly why I use strace-based to sandbox ALL dependencies: https://github.com/ossillate-inc/packj

reply

louislang 10 hours ago

root parent prev next [–]

Phylum's extension framework is built on Deno for this exact reason. The ability to provide granular permissions was something we were really interested in.

Deno is a really cool project, imo.

reply

comprev 9 hours ago

root parent prev next [–]

Interesting read, thanks.

reply

bernawil 6 hours ago

parent prev next [–]

A resource access model for dependencies doesn't make much sense to me, there's basically only 2 things you want to gate access for libraries: filesystem and network. And it's all-in. A library that needs network access may be legit today and after an update start exfiltrating data to a different url. It seems easier to grep for fs and network calls in the library code than any of that.

reply

rollcat 9 hours ago

parent prev next [–]

Check out OpenBSD?'s pledge(2): https://man.openbsd.org/pledge.2

It does exactly that (although on a per-process basis).

I don't think this kind of permission system can be retrofitted into an existing language without direct OS support, and probably not at the library level (you'd need something like per-page permissions which would get hairy real fast).

reply

dilawar 6 hours ago

root parent next [–]

I think @jart has been porting it to Linux https://justine.lol/pledge/ .

reply

musicale 9 hours ago

root parent prev next [–]

I like this. I'd try to keep the permission sets as small, limited, and simple as possible though.

reply

rollcat 9 hours ago

root parent next [–]

> I'd try to keep the permission sets as small and simple as possible though.

You've described OpenBSD? in general. I recommend a deeper dive - it's fantastically refreshing, how simple yet functional an OS can be.

reply

reply

jjav 10 hours ago

parent prev next [–]

This is essentially the fine-grained control the Java Security Manager enabled. But hardly anyone used it and it was deprecated sadly.

reply

charleslmunger 8 hours ago

root parent next [–]

And it didn't really work in practice. Every callback or thread hop is a security vulnerability by default.

reply

pjmlp 53 minutes ago

parent prev next [–]

Java and .NET had it, and in both cases they eventually dropped it, because many security exploits were cause by developers not really understanding how to use them.

In the end they became yet another attack vector, and now everyone should use OS security services instead.

reply

louislang 10 hours ago

parent prev next [–]

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

reply

---

https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon

"To allow JIT compilation in your app, navigate to the Hardened Runtime capability in Xcode and enable the Allow Execution of JIT-compiled Code option for your app. When you enable this option, Xcode adds the com.apple.security.cs.allow-jit entitlement to your app. When this entitlement is present, the system allows your app to call mmap with the MAP_JIT flag." "Disable Write Protections Before You Generate Instructions" " Call mmap with the MAP_JIT option to create a memory region for the new machine instructions.

    Call pthread_jit_write_protect_np with the value false to disable JIT write protections for the memory region in the current thread.
    Write the machine instructions to the memory region."

"Restore Write Protections Before You Execute Instructions"

" Call pthread_jit_write_protect_np with the value true to enable JIT write protections for the memory region in the current thread. This call gives the thread readable and executable (R-X) access to the memory region.

    Call sys_icache_invalidate(_:_:) to invalidate the processor memory caches.
    Jump to the first instruction in the memory region.

Always call sys_icache_invalidate(_:_:) before you execute the machine instructions on a recently updated memory page. On Apple silicon, the instruction caches aren’t coherent with data caches, and unexpected results may occur if you execute instructions without invalidating the caches. "

---

" Never deserialize untrusted data. This happened the most in PHP, because for some reason, PHP developers love to serialize/deserialize objects instead of using JSON, but I’d say almost every case we saw where a server was deserializing a client object and parsing it led to a horrible exploit. For those of you who aren’t familiar, Portswigger has a good breakdown of what can go wrong (incidentally, focused on PHP. Coincidence?). In short, the common thread in all deserialization vulnerabilities is that giving a user the ability to manipulate an object that is subsequently used by the server is an extremely powerful capability with a wide surface area. It’s conceptually similar to both prototype pollution, and user-generated HTML templates. The fix? It’s far better to allow a user to send a JSON object (it has so few possible data types), and to manually construct the object based on the fields in that object. It’s slightly more work, but well worth it! " -- https://kenkantzer.com/learnings-from-5-years-of-tech-startup-code-audits/

--- CHERI stuff

[1]

the CHERI api is here CHERI C/C++ Programming Guide section 7 page 28, "C APIS TO GET AND SET CAPABILITY PROPERTIES"

https://tratt.net/laurie/blog/2023/two_stories_for_what_is_cheri.html

https://capabilitiesforcoders.com/

---

i think the stuff to read for CHERI to learn how we might add some capabilities (but not as complex as CHERI) to Boot and Ovm might be:

CHERI C/C++ Programming Guide section 7 page 28, "C APIS TO GET AND SET CAPABILITY PROPERTIES"

Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 9) Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 9) page 97 (actually can start on page 98) 3.7 Capability-Aware Instructions and some of the earlier parts of chapter 3 talks about registers, etc

---

    5
    cadey 21 hours ago | link | flag | 

What’s the difference between open and openat?

    6
    david_chisnall 18 hours ago | link | flag | 

Openat takes a file descriptor as a base argument and resolves relative to that. On FreeBSD? and Linux, it can be instructed to not travers .. in the base, so always gives a result constrained to the tree specified by the file descriptor that you use as the authorising capability.

FreeBSD’s? Capsicum builds on the *at family of calls in two ways:

    It provides fine-grained (monotonically decreasing) rights on file descriptors, making them real capabilities.
    It removes the non-at-suffixed versions and anything else that modifies the global namespace.

WASI adopts a subset of the Capsicum model.

Rust’s cap-std builds a higher-level standard library around these abstractions, giving a nice capability model for filesystem access.

I don’t know why you’d write new secure software in Rust and not use cap-std as your base.

---