From usability perspective it seems a bit weird that one has to run:
sudo sandbox-app-launcher program [OPTIONS]
I.e. weird that user has to use sudo.
I however understand that from a technical perspective, sandbox-app-launcher needs to run
sudo -H -u "${app_user}" bash -c "
bwrap
which requires sudo.
Could we somehow simplify things for the user so the user could just run
sandbox-app-launcher program [OPTIONS]
instead of
sudo sandbox-app-launcher program [OPTIONS]
?
This seems specifically useful since sandbox-app-launcher cannot support running applications as root anyhow. Running sudo sandbox-app-launcher program [OPTIONS] implies that the application runs as root which it doesn’t.
From a usability perspective, running sudo sandbox-app-launcher should actually tell:
ERROR: Running applications as root with sandbox-app-launcher is unsupported.
Could we add a sudo wrapper for sandbox-app-launcher? Here is the idea:
- rename /usr/bin/sandbox-app-launcher to /usr/lib/sandbox-app-launcher
- introduce /usr/bin/sandbox-app-launcher with contents
#!/bin/bash
sudo /usr/lib/sandbox-app-launcher ${@}
- introduce /etc/sudoers.d/sandbox-app-launcher with contents
## All sudoers to run without a password.
%sudo ALL=NOPASSWD: /usr/bin/sandbox-app-launcher *
Or even…
## All users in group 'user' to run sandbox-app-launcher without a password.
%user ALL=NOPASSWD: /usr/bin/sandbox-app-launcher *
But now we need to think about the security issues of that. The asterisk (“*”) in /usr/bin/sandbox-app-launcher * could be an issue? Attack surface?
- A compromised user account could run each and every application under
sandbox-app-launcher and thereby generate a lot useless app_user sandbox-${app_name} linux user accounts. This could be ignored for now since there are probably many opportunities for denial of service attacks from a locally compromised user account.
- Do you see any other issues? Would this give access to things which would otherwise not be accessible without
sudo access?
This is important in context of PERSISTENT mode USER…
…which will be a boot mode where there is no sudo/root access for the user. In such a boot mode, sandbox-app-launcher would also be most useful.
What kind of security issues I am having in mind…
Currently we use:
if [ -f "/etc/sandbox-app-launcher/${app_name}.conf" ]; then
. "/etc/sandbox-app-launcher/${app_name}.conf"
fi
Which seems fine.
However, if we had source /home/user/.sandbox-app-launcher/config that would be really bad, because then user user without access to sudo / root would get the ability the execute commands as root.
Also if we didn’t use quotes for "/etc/sandbox-app-launcher/${app_name}.conf" there might be a possibility to specifically craft variable app_name (using ../ or similar) to make it source a file writeable in user home folder too. However, we already sanitize variable app_name so we wouldn’t have this issue either.
Also putting a fake (attacker) binary into ~/bin for purpose of getting a malicious variable app_name is not possible either since sudo sanitizes environment variables among PATH (which of course removes user’s ~/bin from PATH).
Similar threat model as restricted APT, rapt.
That kind of security issues I am having in mind. Do you see any of these?