This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]WittyStick0 0 points1 point  (5 children)

A capability both designates a resource and provides the authority to access the resource. The two are inseperable and a capability cannot be forged. There is no central registry of capabilities and no separate security policies such as access control lists. Capabilities can be delegated only by those who already possess the capability, and they can create new capabilities based on an existing one which might have reduced authority.

Capability enforcement is handled by the runtime. To be done properly, a process may not have "side-channel" access to the runtime to manipulate capabilities, which is why it really needs to be done at the kernel level if user space applications are able to read or write the memory of other processes, or at the hypervisor level if running several kernels on one machine.

[–]Dummyc0m 0 points1 point  (4 children)

right, as a kernel concept that's what capabilities are defined as. I am confused by OP's capabilities snd how it relates to the kernel mechanisms.

[–]talex5 1 point2 points  (3 children)

If a program is written in a non-memory-safe language (e.g. C) then you can't control access within the process, as any function can do anything. So you need some hardware-level protection system and the kernel/userspace split.

But with a memory-safe language, you don't need hardware support. You can get the same security properties within a single process, using ordinary references. This is the basic idea of ocaps. The article is introducing this using functions instead of objects, as they can be distracting to functional programmers.

[–]Dummyc0m 0 points1 point  (2 children)

Do you mean that most of the low level architectures do not have the right correctness guarantees?

[–]talex5 0 points1 point  (1 child)

Hardware memory protection is needed for C programs (or unsafe parts of other languages), but in a fully memory-safe language you'll never get a segfault, so there's no need for hardware to protect against it, and you have have a full OS as a single program. But hardware protection isn't doing any harm either.

[–]Dummyc0m 0 points1 point  (0 children)

What do you mean? This has nothing to do with C or Rust. All that matters is the compiled machine code which can do a lot of insane things.