Indeed. User would have to re-run setup, which is bad usability. Would be better if we could fix that automagically for the user.
In theory, yes. But during run_program() sandbox-app-launcher is run as user, not root. Therefore I don’t see how that’s possible. If a have a solution, please implement or let me know.
I have one idea that would be doable, though.
At the moment the tests during setup() look like this:
if ! [ "$(stat -c %a "${shared_dir}")" = "1777" ]; then
chmod 1777 "${dir}"
fi
I.e.
- Test if already done.
- Do whatever needed not already done.
What could be done when running as user, without root, during run_program() is instead:
- Test if already done.
- If root, do it if not yet done. | If user, notify user and error exit.
run_if_root() {
if [ "$sal_is_run_with_root" = "true" ]; then
"$@"
else
echo "ERROR: The setup for this program is incomplete. To fix, please execute:
sudo sandbox-app-launcher setup ${app_name}
(Debugging information: $@)" >&2
exit 1
fi
}
if [ "$(id -u)" = "0" ]; then
sal_is_run_with_root=true
fi
if ! [ "$(stat -c %a "${shared_dir}")" = "1777" ]; then
run_if_root chmod 1777 "${dir}"
fi
What do you think?
Merged.
That would be a good idea.
I implemented a way to stub SIOCGIFHWADDR (and other syscalls if the need arises) with LD_PRELOAD.
I haven’t created a pull request yet because I want to know what you think of it. This will prevent apps using SIOCGIFHWADDR (like Telegram) from dying without actually exposing the MAC address. Right now, it just exits with a return code of 0 but in the future, we could make it return a legitimate MAC address shared amongst all sandbox-app-launcher users.
grep -qE “NAME="Debian GNU/Linux"|NAME="Ubuntu"” /etc/os-release
What do you think about…
grep --quiet --invert-match --extended-regexp 'NAME="Debian|NAME="Ubuntu' /etc/os-release
Good? Better?
All merged.
On a second thought… With the goal of code simplicity… Does sandbox-app-launcher get involved with privacy? Overextending project scope? Is that the right level to handle privacy issues?
If privacy matters, use a (Whonix or other) VM. Then it’s not a real hardware serial.
Much better.
Sandboxing / permission models are fundamentally involved with privacy. If not, you could also make an argument for removing the camera, webcam, etc. permissions too. I don’t think restricting access to identifiers would be out of scope.
How should we handle updates to the seccomp filter? Currently, the binaries won’t be recompiled if we were to update it. Could we move the seccomp filter generation into an apt install script that’s executed on every update? This would also simplify the main script a bit.
Improved in git master.
I see. For microphone, webcam I see a very strong rationale. Nobody wants a compromised application that doesn’t have legitimate use for these devices to turn these on after application compromise. One of the worse possible privacy breaches. MAC addresses have a lot lower severity, well, at least in a VM.
Feasible to blacklist enough identifiers due or VM Fingerprinting making that infeasible?
There’s tons of hardware identifies. (Many listed here: Protocol Leak and Fingerprinting Protection) Feasible to go for it or would that be similar to re-inventing a VM or full emulation?
We don’t have to blacklist identifiers since our AppArmor and seccomp policy are default-deny. Identifiers must be specifically whitelisted. In the case of MAC addresses, the issue was that I didn’t want to whitelist it.
We have fine-grained restrictions on filesystems like /sys and /proc which kills most identifiers already. machine-id is already spoofed (sandbox-app-launcher/machine-id at master · madaidan/sandbox-app-launcher · GitHub) and we could spoof other potential identifiers in a similar fashion. It wouldn’t be very difficult.
Then I guess, go for it.
Merged.
These are application specific or for all applications?
Yes. Moving to Debian maintainer postinst script would be appropriate if for all applications.
(Even if application specific this could be considered.)
Getting things out of the main script can also be good.
All applications.
All merged.