https://futureofcoding.org/ logo
Join Slack
Powered by
Object capabilities represent a shift in the way w...
# thinking-together
j
Object capabilities represent a shift in the way we think about access control and security in software systems. Rather than relying on traditional user-based or role-based access control mechanisms, object capabilities grant access based on the specific capabilities an object possesses. Object capabilities are first class and can be narrowed down to arbitrary granularity by the programmer. • What are the implications of object capabilities for the design and architecture of software systems? How do they impact the modularity, flexibility, and scalability of these systems, and how do they influence our understanding of software architecture more generally? • How can we best leverage object capabilities to promote the development of more secure and resilient software systems? What are the potential pitfalls and challenges associated with this approach, and how can we address them? • How do object capabilities relate to broader philosophical debates about the nature of objects and their properties? Do these capabilities represent a fundamentally new way of thinking about the relationship between objects and their properties, or are they simply a new instantiation of existing concepts?
d
Hi Joakim, do you have a link to quickly and clearly summarise "object capabilities", esp comparing to traditional, for those of us who don't know?
j
@Duncan Cragg 3 minutes:

https://www.youtube.com/watch?v=br9DwtjqmVI▾

The idea is that instead of programs having permissions, permissions are first class values that are passed to the program or supplied at runtime, such as via a OS file picker. These capabilities are then passed around in the program via function arguments, and they can be wrapped etc. to form smaller capabilities, thereby affording a very natural and granular security model.
In some sense, it's already a very popular model today, via dependency injection, where you explicitly pass in specific services that some code needs, rather than having that functionality gloabally available. Object capabilities essentially takes this programming pattern to its logical conclusion, and uses it as the security model as well.
To take Log4Shell as a recent example, you might become suspecious if your logging framework explicitly asks for the capability to download and execute code. But when it just implicitly has those capabilities, nobody bats an eye.
d
Ah, OK, I'm still waiting for my Ah-ha! moment on this... I get the ACL Bad part now, just struggling with the Capabilities Good, or even the What are They?! So tokens for a permission for, the bearer? to do something?
j
Yes, you can view them as unforgable tokens that lets you do specific things, such as reading a certain file.
d
Is "you" the bearer in the code or is "you" a type of thing in the system, presumably it's not the user?
Apologies to side track your OP, btw 😁
j
Here's a code example. You'll have to excuse I'm using my own language Firefly here. In Firefly, 
main
receives 
System
, which is an object representing access to "everything". It contains other capabilities, such as the 
FileSystem
, which represents access to the file system. You can further wrap such capabilities yourself to narrow them down, e.g. to only allow access to files in a particular directory.
Here 
deleteDirectory
is able to delete files because it's passed a 
FileSystem
, whereas 
parsePackageLocation
can do no such thing, since it isn't passed any capabilities.
d
OK, so still, what is the agent that has the capability, that's checked when the filesystem is asked to do something? Is it simply the bearer, or is the token cross-checked to a user, or to an executable?
Also, without decompiling this program, you don't know it isn't deleting all your files, assuming "System" is actually all the user's permissions
j
The token is an imperfect analogy in this case. It's simply an object that's able to access the file system. The constructor is private, which is how the language enforces that it's unforgable (togehter with a strict type system).
Yes, that's right - so Firefly only uses object capabilities internally to protect against exploits from e.g. dependencies. You can go further if you build a whole operating system around this.
d
Ah I see
j
To some degree, browsers and phones employ a form of object capabilities when it comes to accessing the users files or devices.
d
I was going to ask you about Android's quite fine-grained permission model
j
For example, the File object in JS represents read-only access to a single file: https://developer.mozilla.org/en-US/docs/Web/API/File
a
An object capability, conceptually, is pretty much a pointer that is (a) unforgeable (no casting integers or whatever) and (b) revokable. If you're doing this at the OS level, the process would be given some capabilities at startup or via IPC. The kernel will keep track of what capabilities a process has and what they're linked to. IIUC it's also keeping track of capabilities that point to the process, e.g. cases where the process wants to offer an IPC interface to other processes; you can think of the those as virtual objects hosted in the process. So yeah, pretty much bearer tokens. The idea is that a "user" only ever possesses capabilities to files they're allowed to delete, so they can only ever pass those files to the delete command. (by this philosophy, I find the idea of a System capability dubious; it sort of works if it's just your main function not trusting its libraries and your language/runtime is fully reference secure and you've disabled opening files by name, but why settle?).
👍 1
j
I agree. The answer to "why settle" is to be part of the near future rather than the far future. It's simply a tradeoff to fit into the existing popular operating systems.
a
Yes, it was a rhetorical "why settle".
3 Views
Open in Slack
PreviousNext
Powered by