System-wide sandboxing framework - sandbox-app-launcher

[Patrick]

madaidan via Whonix Forum:

Add 20software_rendering_in_vms by madaidan · Pull Request #51 · Kicksecure/sandbox-app-launcher · GitHub

Merged.

xsession_d_file_list_executable=(
  "20torbrowser"
  "20uwt"
  ...
)

for file_name in "/etc/X11/Xsession.d/${xsession_d_file_list_executable[@]}" ; do

I don’t think this code would work. Tested. Would expand to:

/etc/X11/Xsession.d/20torbrowser

20uwt

String /etc/X11/Xsession.d/ could be inside the for loop. That would
work.

But I don’t see much advantage in that. Trading a bit shorter contents
inside the variable assignment at the cost of higher complexity inside
the for loop. Using the full file names such as
/etc/X11/Xsession.d/20uwt makes it easier to grep (the whole Whonix)
source code. As currently implemented, code is easier to understand.
Currently one can copy/paste one string, the file name, and then use cat
or open in an editor to view the file. By making it
/etc/X11/Xsession.d/ + variable it gets harder. Then one has to
understand this a bit better, copy/paste /etc/X11/Xsession.d/ (or
manually write) + the variable name (such as 20uwt).

[Patrick]

Would it be possible to combine sandbox-app-launcher with constrained system resources program starter wrapper? Either by one script calling the other. Which one would run which? Or by adding similar code to sandbox-app-launcher?

sandbox-app-launcher currently attempts to improve security by isolating applications in a sandbox. It however does not yet have any defenses against denial of service (DOS) by exhausting system resources. Either as part of an actual DOS attack (compromised application doing DOS). Or as an attempt to prevent a buggy application from slowing down or even freezing the system.

[HulaHoop]

what general purpose system utilities can be integrated for DoS resistance? Are the defaults sane?

[Patrick]

@HulaHoop

what general purpose system utilities can be integrated for DoS resistance?

There doesn’t seem to be much available against local source DoS (equals misbehaving buggy applications). See constrained system resources program starter wrapper.

Are the defaults sane?

I don’t think there are any default restrictions in Debian at all.

[Patrick]

Kernel Hardening - security-misc

Related to Linux kernel user namespaces: Debian package bubblewrapwill set kernel.unprivileged_userns_clone=1 in Debian bullseye and above. bubblewrap will be no longer suid by default. https://forums.whonix.org/t/flatpak-as-a-software-source-flathub-as-a-source-of-software/8500/17

[madaidan]

@Patrick

Would it be possible to combine sandbox-app-launcher with constrained system resources program starter wrapper ? Either by one script calling the other. Which one would run which? Or by adding similar code to sandbox-app-launcher?

We should probably add similar code to sandbox-app-launcher.

@Patrick

It however does not yet have any defenses against denial of service (DOS) by exhausting system resources. Either as part of an actual DOS attack (compromised application doing DOS). Or as an attempt to prevent a buggy application from slowing down or even freezing the system.

We do use AppArmor to enforce a maximum of 200 processes as a basic protection but we should definitely invest in more.

sandbox-app-launcher/etc/apparmor.d/abstractions/sandbox-app-launcher at master · Kicksecure/sandbox-app-launcher · GitHub

More on rlimit rules: apparmor.d(5) — apparmor — Debian buster — Debian Manpages

@HulaHoop

Are the defaults sane?

No, the dreaded :(){ :|:& };: can still be used to trivially wreck a system.

[Patrick]

sudo sandbox-app-launcher setup url_to_unixtime

sandbox-app-launcher run url_to_unixtime

ERROR: The sandbox for this program has not been set up yet. Please execute:

sudo sandbox-app-launcher setup url_to_unixtime

bash -x sandbox-app-launcher run url_to_unixtime

...
+ '[' -d /home/sandbox-app-launcher-appdata/url_to_unixtime ']'
+ echo 'ERROR: The sandbox for this program has not been set up yet. Please execute:

sudo sandbox-app-launcher setup url_to_unixtime'
ERROR: The sandbox for this program has not been set up yet. Please execute:

sudo sandbox-app-launcher setup url_to_unixtime

ls /home/sandbox-app-launcher-appdata/url_to_unixtime

ls: cannot access ‘/home/sandbox-app-launcher-appdata/url_to_unixtime’: Permission denied

That test…

if [ -d “${app_homedir}” ]; then

Cannot work because user user has no permission to check that. How can we solve that?

[Patrick]

Found a solution. And fixed some other things too.

fix permissions if messed up by something

---

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

to

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

?

[Patrick]

@Patrick

Or better change

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

to

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

?

That does not work. Same error.

[Patrick]

create /etc/machine-id if not existing

[Patrick]

Should file

/etc/sandbox-app-launcher/url_to_unixtime.conf

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

allow_net=yes
allow_webcam=no
allow_mic=no
shared_storage=read-only
allow_dynamic_native_code_exec=yes

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

---

Also a setting

shared_storage=no

would be good?

[Patrick]

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?

[madaidan]

@Patrick

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?

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.

@Patrick

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

sdwdate.

@Patrick

Also a setting

shared_storage=no

would be good?

Yes. Also see if allow_dynamic_native_code_exec=no works. If so, add that too.

@Patrick

Do you think you could make url_to_unixtime work please?

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?

[Patrick]

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.

@madaidan

Is this the same issue as sdwdate and sdwdate-gui development thread?

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.

@madaidan

Are you trying to use systemd sandboxing and sandbox-app-launcher together?

Yes I was wondering if that makes any sense.

@madaidan

Or a custom url_to_unixtime AppArmor profile (not the default sandbox-app-launcher profile) with the rest of sandbox-app-launcher?

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?

[madaidan]

@Patrick

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?

AppArmor + systemd hardening would make more sense since it’s native and allows for more fine-grained restrictions.

@Patrick

Yes I was wondering if that makes any sense.

No, it wouldn’t work and would be redundant even if it did.

@Patrick

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?

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.

[madaidan]

Portability

[Patrick]

Thanks. Missed that one. Answered just now.

[HulaHoop]

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

Microsoft Security Researcher Proposes Unprivileged Chroot For Linux

[madaidan]

Mount namespaces / AppArmor provide greater flexibility for us.

[madaidan]

fix permissions if messed up by something

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.