5 ms·

That whole handle idea of the 'capability' system, but especially its implementation with 'handles', sounds exactly like Win32 to me. I haven't looked at the so

by SCHiM 10y ago

That whole handle idea of the 'capability' system, but especially its implementation with 'handles', sounds exactly like Win32 to me. I haven't looked at the source, can anyone confirm or explain what exactly is different?

adrianratnapala 10y ago
I'm no Windows expert, so I didn't know that windows handles were used as security primitives. I thought they were just a bit like file-descriptors or X11 window ids, or indeed pointers. Such handles do have a kind of role in authorization: once a process has convinced the system to give it some resource, then the (handle, processid) pair is all the system needs to check access. However you typically gain the handle through something like `open()`, i.e. an ACLed request for a named resource. But with true capabilities you just inherit authorisation from some other capability -- possibly one granted to you by a different process. That said, the difference from existing systems might be small. Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL.
- naasking 10y ago
  > Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL. Not necessarily. If your system supports first-class namespaces, then you can just build a namespace consisting of only the objects to which a program should have access. No need for any further access control. A file open dialog from a program is simply the program's request for you to map a file into its namespace.
  - catern 10y ago
    >Not necessarily. If your system supports first-class namespaces, then you can just build a namespace consisting of only the objects to which a program should have access. No need for any further access control. Unfortunately this is usually quite heavyweight. In Unix-like systems, and in Plan 9, the canonical way to do this is to implement a filesystem. "Filesystem" is the universal IPC layer. But implementing a filesystem usually takes quite a lot of effort. Do you know of any systems where this can be done easily enough for it to be used ubiquitously? One would much prefer to just put together a hierarchy of objects at the language level and automatically expose it... or something like that anyway.
    - naasking 10y ago
      > "Filesystem" is the universal IPC layer. But implementing a filesystem usually takes quite a lot of effort. It needn't be. A file system is just a set of nested hashtables. The complexity of traditional file systems comes from the durable representation, but that isn't necessarily needed for first-class namespaces. You can just serialize and deserialize a namespace as needed on top of an ordinary file system. > Do you know of any systems where this can be done easily enough for it to be used ubiquitously? Plan 9 obviously. The Plash capability secure shell [1]. There are probably a couple of others, but not too many overall. [1] http://www.cs.jhu.edu/~seaborn/plash/plash-orig.html http://www.cs.jhu.edu/~seaborn/plash/plash-orig.html
      - catern 10y ago
        I explicitly mentioned Plan 9. Plan 9 doesn't do anything to make it fundamentally easier to write a filesystem, it just takes the (wise) approach of standardizing a simple filesystem protocol. (Which is a big help practically of course.) Nevertheless, actually implementing that protocol is still difficult. While it would be nice to represent a filesystem as a nested hashtable, 9P doesn't give you that for free: you need to keep track of fids you hand out. Plash uses capabilities aggressively and only gives subprocesses access to what they need to access. But it doesn't make it any easier to write new applications which construct namespaces and proxy access.
  - adrianratnapala 10y ago
    Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree. There might be good ways of implementing that, but it's not obvious. On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security. Essentially it would define the semantics of things like cgroups and chroot jails. In fact sometimes I think that mainstream virtualisation is slowly reinventing -- in an incremental way -- what various alternative OSes advocated in a radical way. E.g. Linux cgroups and "one process per container" sounds quite a lot like Plan9's per-process view of the system.
    - naasking 10y ago
      > Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree. First-class namespaces are an implmentation of capabilities. You wouldn't necessarily need capabilities on top of that. You'd pass around namespaces or perform namespace mappings to grant or revoke authorities. > On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security. You can use ACLs to implement capabilities [1], which the capability folks did with Windows XP as a proof of concept with a modern OS [2] (I don't know why Microsoft didn't just adopt Polaris to be frank). But in general you shouldn't use ACLs to try augment capabilities. They restrict the class of expressible security policies without actually adding security (and in fact, they introduce insecurity). [1] http://www.webstart.com/jed/papers/Managing-Domains/ http://www.webstart.com/jed/papers/Managing-Domains/ [2] http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html
david-given 10y ago
Roughly put: in a capability based system, if you have a valid handle for a service, then you can use that service. But the only way you can get a valid handle is to ask your parent process for one --- handles are unforgeable. So your parent gets to check that you're legitimate. ...but your parent, in turn, has limited permissions, because the only way it can get a handle is to ask its parent. And when you ask your parent for a filesystem handle, your parent doesn't have to give you the handle it has. Your parent might give you a limited filesystem handle which only allows writes to /tmp. ...and when you, in turn, start a subprocess --- say, an instance of sqlite for use as a database --- you have to give it handles for the things it wants to do on your behalf. But your filesystem handle only allows writes to /tmp. That means that your sqlite instance can only write to /tmp too. There's more to it than that, because in real life you also want to forward capabilities to other running services as part of RPCs, but you tend to end up with a natural container system with multiple redundant layers of isolation, all running at minimum necessary privilege, and all hardware-mediated. Another really interesting capability-based OS is Genode: https://genode.org/about/screenshots https://genode.org/about/screenshots https://genode.org/documentation/general-overview/index https://genode.org/documentation/general-overview/index It'll allow you to run complete OS kernels as capability-restricted Genode processes, effectively allowing virtual machines as first-class citizens.
- monocasa 10y ago
  So, going back to Win32, it's as if OpenFile also took a HANDLE that represented your abilities (or capabilities if you will ) within the security model, with the explicit ability to forward these handles (or new handles that represent a subset of the original's capabilities) to other processes if you choose.
  - jvert 10y ago
    In Win32, this handle is called the AccessToken https://msdn.microsoft.com/en-us/library/windows/desktop/aa374909(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... and the calling thread's current access token is used by OpenFile to grant or deny the requested access.
- 10y ago
swetland 10y ago
https://fuchsia.googlesource.com/magenta/+/master/docs/concepts.md https://fuchsia.googlesource.com/magenta/+/master/docs/conce... https://fuchsia.googlesource.com/magenta/+/master/docs/syscalls.md https://fuchsia.googlesource.com/magenta/+/master/docs/sysca... It's early days. The API surface is still evolving.

by SCHiM 10y ago

adrianratnapala 10y ago

I'm no Windows expert, so I didn't know that windows handles were used as security primitives. I thought they were just a bit like file-descriptors or X11 window ids, or indeed pointers. Such handles do have a kind of role in authorization: once a process has convinced the system to give it some resource, then the (handle, processid) pair is all the system needs to check access. However you typically gain the handle through something like `open()`, i.e. an ACLed request for a named resource. But with true capabilities you just inherit authorisation from some other capability -- possibly one granted to you by a different process. That said, the difference from existing systems might be small. Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL.

naasking 10y ago
> Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL. Not necessarily. If your system supports first-class namespaces, then you can just build a namespace consisting of only the objects to which a program should have access. No need for any further access control. A file open dialog from a program is simply the program's request for you to map a file into its namespace.
- catern 10y ago
  >Not necessarily. If your system supports first-class namespaces, then you can just build a namespace consisting of only the objects to which a program should have access. No need for any further access control. Unfortunately this is usually quite heavyweight. In Unix-like systems, and in Plan 9, the canonical way to do this is to implement a filesystem. "Filesystem" is the universal IPC layer. But implementing a filesystem usually takes quite a lot of effort. Do you know of any systems where this can be done easily enough for it to be used ubiquitously? One would much prefer to just put together a hierarchy of objects at the language level and automatically expose it... or something like that anyway.
  - naasking 10y ago
    > "Filesystem" is the universal IPC layer. But implementing a filesystem usually takes quite a lot of effort. It needn't be. A file system is just a set of nested hashtables. The complexity of traditional file systems comes from the durable representation, but that isn't necessarily needed for first-class namespaces. You can just serialize and deserialize a namespace as needed on top of an ordinary file system. > Do you know of any systems where this can be done easily enough for it to be used ubiquitously? Plan 9 obviously. The Plash capability secure shell [1]. There are probably a couple of others, but not too many overall. [1] http://www.cs.jhu.edu/~seaborn/plash/plash-orig.html http://www.cs.jhu.edu/~seaborn/plash/plash-orig.html
    - catern 10y ago
      I explicitly mentioned Plan 9. Plan 9 doesn't do anything to make it fundamentally easier to write a filesystem, it just takes the (wise) approach of standardizing a simple filesystem protocol. (Which is a big help practically of course.) Nevertheless, actually implementing that protocol is still difficult. While it would be nice to represent a filesystem as a nested hashtable, 9P doesn't give you that for free: you need to keep track of fids you hand out. Plash uses capabilities aggressively and only gives subprocesses access to what they need to access. But it doesn't make it any easier to write new applications which construct namespaces and proxy access.
- adrianratnapala 10y ago
  Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree. There might be good ways of implementing that, but it's not obvious. On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security. Essentially it would define the semantics of things like cgroups and chroot jails. In fact sometimes I think that mainstream virtualisation is slowly reinventing -- in an incremental way -- what various alternative OSes advocated in a radical way. E.g. Linux cgroups and "one process per container" sounds quite a lot like Plan9's per-process view of the system.
  - naasking 10y ago
    > Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree. First-class namespaces are an implmentation of capabilities. You wouldn't necessarily need capabilities on top of that. You'd pass around namespaces or perform namespace mappings to grant or revoke authorities. > On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security. You can use ACLs to implement capabilities [1], which the capability folks did with Windows XP as a proof of concept with a modern OS [2] (I don't know why Microsoft didn't just adopt Polaris to be frank). But in general you shouldn't use ACLs to try augment capabilities. They restrict the class of expressible security policies without actually adding security (and in fact, they introduce insecurity). [1] http://www.webstart.com/jed/papers/Managing-Domains/ http://www.webstart.com/jed/papers/Managing-Domains/ [2] http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html http://www.hpl.hp.com/techreports/2004/HPL-2004-221.html

david-given 10y ago

Roughly put: in a capability based system, if you have a valid handle for a service, then you can use that service. But the only way you can get a valid handle is to ask your parent process for one --- handles are unforgeable. So your parent gets to check that you're legitimate. ...but your parent, in turn, has limited permissions, because the only way it can get a handle is to ask its parent. And when you ask your parent for a filesystem handle, your parent doesn't have to give you the handle it has. Your parent might give you a limited filesystem handle which only allows writes to /tmp. ...and when you, in turn, start a subprocess --- say, an instance of sqlite for use as a database --- you have to give it handles for the things it wants to do on your behalf. But your filesystem handle only allows writes to /tmp. That means that your sqlite instance can only write to /tmp too. There's more to it than that, because in real life you also want to forward capabilities to other running services as part of RPCs, but you tend to end up with a natural container system with multiple redundant layers of isolation, all running at minimum necessary privilege, and all hardware-mediated. Another really interesting capability-based OS is Genode: https://genode.org/about/screenshots https://genode.org/about/screenshots https://genode.org/documentation/general-overview/index https://genode.org/documentation/general-overview/index It'll allow you to run complete OS kernels as capability-restricted Genode processes, effectively allowing virtual machines as first-class citizens.

monocasa 10y ago
So, going back to Win32, it's as if OpenFile also took a HANDLE that represented your abilities (or capabilities if you will ) within the security model, with the explicit ability to forward these handles (or new handles that represent a subset of the original's capabilities) to other processes if you choose.
- jvert 10y ago
  In Win32, this handle is called the AccessToken https://msdn.microsoft.com/en-us/library/windows/desktop/aa374909(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... and the calling thread's current access token is used by OpenFile to grant or deny the requested access.
10y ago

swetland 10y ago

https://fuchsia.googlesource.com/magenta/+/master/docs/concepts.md https://fuchsia.googlesource.com/magenta/+/master/docs/conce... https://fuchsia.googlesource.com/magenta/+/master/docs/syscalls.md https://fuchsia.googlesource.com/magenta/+/master/docs/sysca... It's early days. The API surface is still evolving.