Bubblewrap as init is a bit awkward and don't support a few setup actions fortify will need, such as starting/supervising nscd.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
There is no good reason to run fortify as root and desktop environments typically do not like that either. This check prevents confusion for new users who might mistakenly run it as root or set the setuid bit.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Bwrap argument order determines the order their corresponding actions are performed. This allows generic arguments like tmpfs to the end of the stream to override bind mounts.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Error handling here is way too monstrous due to terrible design of the internal/app package. Since rewriting internal/app will take a while, error handling is moved out of main to improve readability.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
This configuration is not saved anywhere, and does not need to be saved. Bwrap configuration information is already saved into p.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Both machinectl and sudo launch methods launch shim as shim is now responsible for setting up the sandbox. Various app structures are adapted to accommodate bwrap configuration and mediated wayland access.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
This implementation of shim accepts configuration as a gob stream over a unix socket, with support for mediating access to wayland via WAYLAND_SOCKET fd. All configuration is now included in the payload, and child is started inside bwrap configured with supplied bwrap.Config.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
ACL operations are now tagged with the enablement causing them. At the end of child process's life, enablements of all remaining launchers are resolved and inverted. This allows Wait to only revert operations targeting resources no longer required by other launchers.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Launch methods serve the primary purpose of setting UID in the init namespace, which bubblewrap does not do. Furthermore, all applications will start within a bubblewrap sandbox once it has been implemented.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Fortify needs to internally resolve helper program sandbox config. They are considered trusted and runs under the privileged UID so ldd output is used to determine libraries they need inside the sandbox environment.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Bubblewrap apparently requires --unshare-user even when --unshare-all is set to apply --disable-userns. This behaviour is not clearly documented.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Tests internal to the helper package sets crash-test-dummy as the command whenever a launch is expected to go through, and the hardcoded args are only valid for internal tests, so this characteristic is used here to exclude external tests that pass real program names and custom bwrap configurations.
Signed-off-by: Ophestra Umiker <cat@ophivana.moe>
Ophestra Umiker