Capabilities are underrated as a generally way to purge bad archictures, make it clearer what code is doing, and generally cut accidental complexity & improve programmer productivity.
This is a big deal, because many security practices are neutral or bad for programmer productivity.
We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear what was a good candidate to get this stuff in prod, now it is very clear that socket-activated services are an idea use-case, with very little migration pain.
Even if you think we should be going to Fuschia or SEl4 or whatever, I think this is a good stepping stone. Those projects are a big jump alone, and funding is uncertain. (Plus there are issues of single-company dominance with Fuchsia.) I think CloudABI is the sort of "non-reformist reform" not "worse is better" stepping stone that would help those projects not hurt them.
Agreed re: the general idea, but isn't CloudABI in particular superseded somewhat by WASI? Its repo seems to say it is: https://github.com/NuxiNL/cloudabi
(WASI is similarly capability-based, as I understand it!)
I don't think so. WASM is changing things on many fronts. CloudABI is just doing one front.
I don't have any thing against WASI, and I don't blame them for wanting to point out a like-minded project that was still active. But just as I think CloudABI is a good stepping stone for seL4 or Fuschia, I think it is a good stepping stone for WASM.
Also, I guess I don't believe in coupling change on in principle independent axes. If you at least allow the knobs to be turned separately, even if you don't e.g. CI or otherwise support all combinations, you are incentivized to handle things more "parametrically" vs if-def soup (which matches capabilities, incidentally!) and you have a great way to troubleshoot stuff. This is like how NetBSD says they like supporting obscure architectures to catch more bugs in the portable code too, not just make their lives harder.
By WASI alone you mean just do something a lot like cloudabi with the home directory emulation baked in?
The idea is the interface, and that is very nice and simple, so sure. But I think the ability to catch on must be in the implementation. I suppose parts of the WASI libc could be reused, but those parts could equally well be taken from the original Musl, right?
Making an embryonic process, mutating it's state as desired, and then submitting to the scheduler is a much nicer workflow, and more in the spirit of capabilities anyways where "fork = duplicate the whole keyring and then destroy some caps" as foolhardy.
FreeBSD already had process/PID FDs, but I think CloudABI avoided them because it wanted to be easier to port. But now that Linux has them too, I don't think this should be a such a portability concern.
4. Bang on drum for other OSes and upstream systemd to implement this stuff we can can good portable abstractions -- I think this is our best shot to get "portable containers".
This is a big deal, because many security practices are neutral or bad for programmer productivity.
We need a big project to get CloudABI implemented in all the major kernels to make the theory reality. Whereas before it was unclear what was a good candidate to get this stuff in prod, now it is very clear that socket-activated services are an idea use-case, with very little migration pain.
Even if you think we should be going to Fuschia or SEl4 or whatever, I think this is a good stepping stone. Those projects are a big jump alone, and funding is uncertain. (Plus there are issues of single-company dominance with Fuchsia.) I think CloudABI is the sort of "non-reformist reform" not "worse is better" stepping stone that would help those projects not hurt them.