This design choice is intended to block malicious connections from managing or running arbitrary commands inside containers as malicious processes.
If your rooting method is compromised, droidspaces, along with all your modules and everything else under the sun, will be compromised too.
Since the daemon uses an abstract socket called @droidspaces, all apps are denied by SELinux anyway, even if I remove the checks. There’s no fix for that without patching SELinux to allow the "untrusted apps" domain to communicate with the socket. But:
We can’t allow untrusted apps to communicate with the daemon via SELinux either. Why? Because that would let any userspace app communicate with the droidspaces app and potentially with any socket in the system, which is extremely dangerous.
The daemon and client are baked into the same droidspaces binary. Also, the binary can directly execute commands if no daemon is found AND it has root. A 3-in-1 solution.
The app requires root anyway to install containers, etc., so even without strict UID checks, the app will partially work.
We can’t use droidspaces as a “command execution environment” for non-root processes to execute root commands needed for the app either. If a vulnerability in droidspaces is exploited, any non-root process could spawn a root shell.
The biggest concern is that the droidspaces binary can execute commands directly inside running containers using the
run command. If any process could connect to the socket, it could enter container shells, execute commands, nuke containers, plant backdoors, etc.This is a massive security risk.
So, until someone implements a kernelsu-like solution to “crown” the official droidspaces manager and block connections from everything else, I won’t implement such a feature.
Even if I did, it would overcomplicate the app’s code. Thanks to our 3-in-1 architecture, I didn’t have to touch any app code; the droidspaces binary acts as a client for the daemon if it detects the socket is alive.