System-wide sandboxing framework - sandbox-app-launcher

Found a solution. And fixed some other things too.

new issue:

sudo --set-home --user=sal-url_to_unixtime bash -c ’
bwrap --ro-bind /bin /bin --ro-bind /usr/bin /usr/bin --ro-bind /lib /lib --ro-bind-try /lib32 /lib32 --ro-bind-try /lib64 /lib64 --ro-bind /usr/lib /usr/lib --ro-bind-try /usr/local/lib /usr/local/lib --ro-bind /usr/share /usr/share --ro-bind-try /usr/local/share /usr/local/share --ro-bind /usr/include /usr/include --ro-bind /etc /etc --ro-bind-data 10 /etc/passwd --ro-bind-data 11 /etc/group --ro-bind /usr/share/sandbox-app-launcher/machine-id /etc/machine-id --ro-bind /var/lib /var/lib --tmpfs /var/lib/dbus --ro-bind /usr/share/sandbox-app-launcher/machine-id /var/lib/dbus/machine-id --ro-bind /sys/devices /sys/devices --ro-bind /sys/class /sys/class --ro-bind /sys/bus /sys/bus --ro-bind /sys/fs/cgroup /sys/fs/cgroup --bind /home/sandbox-app-launcher-appdata/url_to_unixtime /home/sandbox-app-launcher-appdata/url_to_unixtime --proc /proc --tmpfs /tmp --ro-bind-try /tmp/.X11-unix /tmp/.X11-unix --tmpfs /var/tmp --tmpfs /var/cache --ro-bind /var/cache/sandbox-app-launcher-autogenerated/wrappers/url_to_unixtime /var/cache/sandbox-app-launcher-autogenerated/wrappers/url_to_unixtime --ro-bind /usr/bin/url_to_unixtime /usr/bin/url_to_unixtime --tmpfs /run --symlink /run /var/run --dev /dev --chdir /home/sandbox-app-launcher-appdata/url_to_unixtime --setenv HOME /home/sandbox-app-launcher-appdata/url_to_unixtime --setenv USER sal-url_to_unixtime --setenv LOGNAME sal-url_to_unixtime --setenv XAUTHORITY /home/sandbox-app-launcher-appdata/url_to_unixtime/.Xauthority --setenv SHELL /sbin/nologin --setenv started_by_sandbox_app_launcher true --unsetenv SUDO_USER --unsetenv SUDO_UID --unsetenv SUDO_GID --unsetenv SUDO_COMMAND --unsetenv OLDPWD --unsetenv MAIL --unshare-pid --unshare-cgroup --unshare-uts --hostname host --new-session --cap-drop all --seccomp 12 10< <(getent passwd root sal-url_to_unixtime nobody) 11< <(getent group root sal-url_to_unixtime nobody) 12< /var/cache/sandbox-app-launcher-autogenerated/seccomp-filter.bpf /var/cache/sandbox-app-launcher-autogenerated/wrappers/url_to_unixtime ’
bwrap: Can’t create file at /etc/machine-id: Read-only file system

File /etc/machine-id does not exist on my test system for some reason. I guess during setup we need to create an empty one if none exists?

Or better change

--ro-bind ${main_app_dir}/machine-id /etc/machine-id


--ro-bind-try ${main_app_dir}/machine-id /etc/machine-id


1 Like

That does not work. Same error.

1 Like
1 Like

Should file


## Copyright (C) 2020 - 2020 ENCRYPTED SUPPORT LP <>
## See the file COPYING for copying conditions.


be added to package sdwdate or sandbox-app-launcher?

Also a setting


would be good?

1 Like

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
AVC apparmor="DENIED" operation="ptrace" profile="sandbox-app-launcher-wx" pid=29770 comm="systemd-detect-" requested_mask="read" denied_mask="read" peer="unconfined"
AVC apparmor="DENIED" operation="open" profile="sandbox-app-launcher-wx" name="/proc/cmdline" pid=29770 comm="systemd-detect-" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
AVC apparmor="DENIED" operation="exec" info="no new privs" error=-1 profile="sandbox-app-launcher-wx" name="/usr/bin/url_to_unixtime" pid=29777 comm="url_to_unixtime" requested_mask="x" denied_mask="x" fsuid=1001 ouid=0 target="/usr/bin/url_to_unixtime"

Do you think you could make url_to_unixtime work please?

1 Like

That’s not the issue. We don’t depend on a preexisting /etc/machine-id. We use sandbox-app-launcher/usr/share/sandbox-app-launcher/machine-id at master · Kicksecure/sandbox-app-launcher · GitHub and overwrite /etc/machine-id within the namespace.

Your issue is:

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.


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?

1 Like

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.

No. Totally different.
To resolve issues of sdwdate and sdwdate-gui development thread - #37 by troubadour I was wondering: could sandbox-app-launcher be used instead.

Yes I was wondering if that makes any sense.

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?

1 Like

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.

1 Like
1 Like

Thanks. Missed that one. Answered just now.

Saw this “new” feature being upstreamed. Don’t know how useful it can be for the sandbox:

1 Like

Mount namespaces / AppArmor provide greater flexibility for us.

1 Like

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.

1 Like
1 Like

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}"


  1. Test if already done.
  2. Do whatever needed not already done.

What could be done when running as user, without root, during run_program() is instead:

  1. Test if already done.
  2. 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
    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

if [ "$(id -u)" = "0" ]; then

if ! [ "$(stat -c %a "${shared_dir}")" = "1777" ]; then
  run_if_root chmod 1777 "${dir}"

What do you think?

1 Like


That would be a good idea.

1 Like
1 Like
1 Like

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.

1 Like