Repository navigation
Capabilities granularity too low #90
Description
Most existing capability-based systems have either of the following issues.
-
Too low granularity of capabilities (an app can access network, but actually should be allowed to access e.g. just several OSI 4 or higher protocols, have limited bandwidth, shouldn't have access to any OSI 3 or lower information, etc.)
-
Too high granularity (e.g. SELinux is super complex which is contra-productive as it's therefore quite often ignored or quite incorrectly configured)
To solve this, capabilites shouldn't be fix, but rather shall be a turing-complete executable code/assembly (imagine Linux BPF JIT). Then one can provide a standard library with low-grained capability-building-blocks (like e.g. Android does) and allow for fine-grained specification in all scenarios.
How do you want to approach this granularity/complexity issue in WASI?
Activity
sunfishcode commentedon Apr 2, 2019
My rough idea is that Mandatory Access Control (MAC) is out of scope for WASI, at least for now. That is, at the point of resolving a filesystem path or configuring a network socket or otherwise obtaining a new resource handle, the host environment may be permitted to apply additional rules to determine if access should be granted, such as SELinux or other systems. As you say, this can be pretty complex.
For filesystem support, WASI currently has a directory-oriented capability model. Wasm code can be granted access to a directory, providing it access to the contents of that directory. This access can be restricted to being readonly or other things, but there's no finer-grained path filtering currently.
For networking support, my rough idea (mentioned here) is that we could introduce a kind of capability which represents a set of sockets that can be created. For TCP-like sockets, this might look like a set of address (source and destination), port (source and destination), and protocol tuples that application code might create and configure a socket on.
My rough idea for both of these is to look for sweet-spot solutions that work for the majority of cases while still being really simple, and leave the more specialized cases to host/environment-specific mechanisms outside of WASI. However, this may also be a result of my lacking experience with BPF-style filtering -- to me, it sounds more complex, sounds like functionality that's only needed in highly specialized circumstances, and any time you add a new turing-complete mechanism to an overall system in a security-relevant area, my generic experience is that you have to be very very cautious.
However, if someone who has more experience with BPF or similar mechanisms wanted to make a writeup showing how it would work for WebAssembly, it'd be a great topic for the CG subgroup to discuss.
npmccallum commentedon Apr 2, 2019
@sunfishcode I don't understand how capabilities are in scope for WASI. Could you clarify this? APIs don't enforce capabilities, implementations of those APIs do.
npmccallum commentedon Apr 2, 2019
As an example, let's say we have TCP-like sockets. We want to restrict the WASM to
connect()only to a single address. If you're running on Linux (most all of us are), you just put the runtime in acgroupand setiptablesrules on thatcgroup. Theconnect()command will fail on everything but the specified address. But this has nothing to do with the API itself. This is entirely enforced by the host OS. Where the host OS doesn't provide such capabilities, the runtime can add them. But it doesn't impact the API.sunfishcode commentedon Apr 2, 2019
Continuing the discussion here now that we have a dedicated repo.
Mark public API functions as unsafe. (#90)
Add a simple bench (bytecodealliance#90)
Merge pull request bytecodealliance#90 from bytecodealliance/pch/impo…
Merge pull request bytecodealliance#90 from bytecodealliance/pch/impo…
Typed continuations + WASI tests (bytecodealliance#90)