3 ms·

> But this compromises the property that actually makes capabilities so much better: unrestricted delegation leads to the principle of least authority via fine-

by Yoric 10y ago

> But this compromises the property that actually makes capabilities so much better: unrestricted delegation leads to the principle of least authority via fine-grained permissions. The fact that capabilities can be passed arbitrarily leads you naturally to defining fine-grained authorizations so that eventual abuse can be minimized, detected, and revoked. Really? I would have assumed that letting anyone send capabilities to anyone without going through the kernel was a highway towards privilege escalation. Do you have documentation on this topic? I'm pretty interested – in particular since I'm hoping to contribute to this fork.

naasking 10y ago
> Really? I would have assumed that letting anyone send capabilities to anyone without going through the kernel was a highway towards privilege escalation. "Unrestricted" in my post doesn't mean "you can send to anyone", it means "no restrictions on passing capabilities beyond that defined by the capability model". The capability security model requires that you can only send capabilities via your other capabilities. So if you have a capability to another process, then you can send any of your other capabilities to that process. The Redox design appears to violate this. The capability model is actually simple and surprisingly common. Take any memory-safe object-oriented language, and remove static mutable state and the file system and network APIs (all sources of "ambient authority"). An object reference is now a capability. Passing an object reference via method parameters is a capability send, and you can only pass around references you actually have, and only to objects to which you have references. That's capability security. You can look at any context and see precisely what side-effects can occur simply by analyzing the set of object references available in that context. It's bad design to define functions that take a huge number of parameters, but it's also bad security. Capability security aligns maintainability concerns with security concerns thus yielding POLA. Edit: as for documentation, I'm not sure if you want OS documentation, or general capability documentation. The seL4 and EROS papers are good for capabilities in operating systems, the E and Joe-E programming languages are good references for capabilities in general.
- Yoric 10y ago
  I am actually pretty familiar with (some instances of) the capability model, in particular process algebra-style capabilities, which pretty much don't limit sending capabilities, but also don't need to deal with Unix-style `fork`, for instance. I was just wondering if you had specific problems in mind. In this case, how would you modify the design? Getting rid of `Kind`, I assume? If so, how would you enable/disable passing capabilities? By having a meta-capability "I can pass capability foo"? That's pretty much how I would do it in a process algebra, but that doesn't look very usable in practice.
  - naasking 10y ago
    > If so, how would you enable/disable passing capabilities? By having a meta-capability "I can pass capability foo"? I would first question why you think you need to disable capability passing at all, which was the main thrust of my post [1]. What specific problem are you trying to solve by restricting capability passing? Perhaps Unix-style 'fork' has some undesirable semantics, but I don't see how restricting capability delegation would solve them. POSIX sandboxes using capabilities have been done a few times, originally KeyKOS and then EROS. Perhaps the most accessible introduction for those coming from a UNIX introduction would be Capsicum [2]. [1] Yes, "kind" classifies capabilities into those that can be passed around without restriction, and those that can't, so I'm questioning the utility of that [2] https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson.pdf https://www.usenix.org/legacy/event/sec10/tech/full_papers/W...
    - Yoric 10y ago
      > I would first question why you think you need to disable capability passing at all, which was the main thrust of my post [1]. What specific problem are you trying to solve by restricting capability passing? Right now, my specific problems #1 (resp. #2) is understanding what you (resp ticki) have in mind :) But I can also think of problems such as: 1/ limiting privilege escalation; 2/ somehow transitively revoking privileges that have been obtained through a compromised process. Not sure if `Kind` has any effect on either, but I'll spend a few days thinking about these issues. I'd be happy to chat with you if you're interested (I'm Yoric on irc.mozilla.org).
btilly 10y ago
It depends on what you mean by "capabilities". My guess is that they consider capabilities to just be a fine-grained permission system. In which case they've lost the battle for a fundamentally improved security system before they've begun. In particular they can't solve the confused deputy problem. (What Linux calls capabilities aren't, for exactly this reason.) The confused deputy problem happens when a process given a permission for one purpose, can be tricked into using that permission for something unrelated. If you attach permissions to processes, then this will happen because "I have permission to do this" is essentially a global variable. What you should be thinking is that a capability is a handle, much like a filehandle or an object. You do things by making calls to that handle. If you don't have the handle, you can't make the call. If you have multiple very similar handles, the one you make the call on matters. That handle ties the attempt to take the action to whether you should have permission for it. Now if you've got handles, you can do something very clever, which is create new handles out of old ones. So, for example, I can take my permissions to read the whole filesystem, and construct a handle that can read from only one directory. I can then pass this new fine grained permission to a process. If that is the only permission it was given, it can never read from anything except the directory. No privilege escalation is possible, ever. You want to be able to create arbitrary capabilities like this and pass them around. The result is that programs get launched not with, "You can do anything I can do" but with, "Here is everything that you will be ever able to do." And this can be verified without ever looking at the source code.

by Yoric 10y ago

naasking 10y ago

> Really? I would have assumed that letting anyone send capabilities to anyone without going through the kernel was a highway towards privilege escalation. "Unrestricted" in my post doesn't mean "you can send to anyone", it means "no restrictions on passing capabilities beyond that defined by the capability model". The capability security model requires that you can only send capabilities via your other capabilities. So if you have a capability to another process, then you can send any of your other capabilities to that process. The Redox design appears to violate this. The capability model is actually simple and surprisingly common. Take any memory-safe object-oriented language, and remove static mutable state and the file system and network APIs (all sources of "ambient authority"). An object reference is now a capability. Passing an object reference via method parameters is a capability send, and you can only pass around references you actually have, and only to objects to which you have references. That's capability security. You can look at any context and see precisely what side-effects can occur simply by analyzing the set of object references available in that context. It's bad design to define functions that take a huge number of parameters, but it's also bad security. Capability security aligns maintainability concerns with security concerns thus yielding POLA. Edit: as for documentation, I'm not sure if you want OS documentation, or general capability documentation. The seL4 and EROS papers are good for capabilities in operating systems, the E and Joe-E programming languages are good references for capabilities in general.

Yoric 10y ago
I am actually pretty familiar with (some instances of) the capability model, in particular process algebra-style capabilities, which pretty much don't limit sending capabilities, but also don't need to deal with Unix-style `fork`, for instance. I was just wondering if you had specific problems in mind. In this case, how would you modify the design? Getting rid of `Kind`, I assume? If so, how would you enable/disable passing capabilities? By having a meta-capability "I can pass capability foo"? That's pretty much how I would do it in a process algebra, but that doesn't look very usable in practice.
- naasking 10y ago
  > If so, how would you enable/disable passing capabilities? By having a meta-capability "I can pass capability foo"? I would first question why you think you need to disable capability passing at all, which was the main thrust of my post [1]. What specific problem are you trying to solve by restricting capability passing? Perhaps Unix-style 'fork' has some undesirable semantics, but I don't see how restricting capability delegation would solve them. POSIX sandboxes using capabilities have been done a few times, originally KeyKOS and then EROS. Perhaps the most accessible introduction for those coming from a UNIX introduction would be Capsicum [2]. [1] Yes, "kind" classifies capabilities into those that can be passed around without restriction, and those that can't, so I'm questioning the utility of that [2] https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson.pdf https://www.usenix.org/legacy/event/sec10/tech/full_papers/W...
  - Yoric 10y ago
    > I would first question why you think you need to disable capability passing at all, which was the main thrust of my post [1]. What specific problem are you trying to solve by restricting capability passing? Right now, my specific problems #1 (resp. #2) is understanding what you (resp ticki) have in mind :) But I can also think of problems such as: 1/ limiting privilege escalation; 2/ somehow transitively revoking privileges that have been obtained through a compromised process. Not sure if `Kind` has any effect on either, but I'll spend a few days thinking about these issues. I'd be happy to chat with you if you're interested (I'm Yoric on irc.mozilla.org).

btilly 10y ago

It depends on what you mean by "capabilities". My guess is that they consider capabilities to just be a fine-grained permission system. In which case they've lost the battle for a fundamentally improved security system before they've begun. In particular they can't solve the confused deputy problem. (What Linux calls capabilities aren't, for exactly this reason.) The confused deputy problem happens when a process given a permission for one purpose, can be tricked into using that permission for something unrelated. If you attach permissions to processes, then this will happen because "I have permission to do this" is essentially a global variable. What you should be thinking is that a capability is a handle, much like a filehandle or an object. You do things by making calls to that handle. If you don't have the handle, you can't make the call. If you have multiple very similar handles, the one you make the call on matters. That handle ties the attempt to take the action to whether you should have permission for it. Now if you've got handles, you can do something very clever, which is create new handles out of old ones. So, for example, I can take my permissions to read the whole filesystem, and construct a handle that can read from only one directory. I can then pass this new fine grained permission to a process. If that is the only permission it was given, it can never read from anything except the directory. No privilege escalation is possible, ever. You want to be able to create arbitrary capabilities like this and pass them around. The result is that programs get launched not with, "You can do anything I can do" but with, "Here is everything that you will be ever able to do." And this can be verified without ever looking at the source code.