Cannot manage to run /usr/bin/url_to_unixtime. (Currently in sdwdate git master and developers repository only.)
sudo bash -x sandbox-app-launcher run url_to_unixtime
/usr/bin/url_to_unixtime
/var/cache/sandbox-app-launcher-autogenerated/wrappers-wx/url_to_unixtime: /usr/bin/url_to_unixtime: /usr/bin/python3: bad interpreter: Operation not permitted
bwrap: Can’t create file at /etc/machine-id: Read-only file system
I.e. /etc is mounted read-only so we can’t add our own machine-id.
sdwdate.
Yes. Also see if allow_dynamic_native_code_exec=no works. If so, add that too.
I’m confused as to what you’re trying to do. Is this the same issue as sdwdate and sdwdate-gui development thread - #376 by Patrick? Are you trying to use systemd sandboxing and sandbox-app-launcher together? Or a custom url_to_unixtime AppArmor profile (not the default sandbox-app-launcher profile) with the rest of sandbox-app-launcher?
I will try to simplify my questions. Try to ignore most context (sdwdate, apparmor issues)…
Does it generally or it some cases make sense to use sandbox-app-launcher for any applications started by systemd units? Or are for systemd units apparmor + systemd hardening more appropriate? Or is systemd-app-launcher better to be only used for user facing applications, specifically GUI applications? (Command line applications often don’t need many of the stuff in /etc/X11/Xsession.d, no need for dbus etc.)
Could you please try to make /usr/bin/url_to_unixtime under sandbox-app-launcher? I cannot make it work under any sandbox-app-launcher configuration.
I didn’t think about that yet. Would be good to document how sandbox-app-launcher interacts with system apparmor profiles. I.e…
When running an application under sandbox-app-launcher, is an apparmor profile in /etc/apparmor.d still in effect or ignored? For example suppose we could run evince (did not test yet) under sandbox-app-launcher. Does /etc/apparmor.d/usr.bin.evince still matter or is it ignored?
AppArmor + systemd hardening would make more sense since it’s native and allows for more fine-grained restrictions.
No, it wouldn’t work and would be redundant even if it did.
It’s ignored and I don’t think we should support other AppArmor profiles. Those other profiles won’t have access to e.g. the sandboxed user’s home directory and thus, would break the application. They may also not be very secure.
Wouldn’t this be better suited in run_program()? Those chmod calls will only execute during setup; it won’t help if something messes up the permissions after setup.
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
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.