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?