System-wide sandboxing framework - sandbox-app-launcher

Patrick · December 25, 2020, 11:45am

madaidan via Whonix Forum:

https://github.com/Whonix/sandbox-app-launcher/pull/51

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 · December 28, 2020, 12:24pm

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 · December 30, 2020, 3:16pm

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

Patrick · December 31, 2020, 3:01pm

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 · January 5, 2021, 6:18am

madaidan · January 12, 2021, 12:20am

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

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

https://github.com/Whonix/sandbox-app-launcher/blob/master/etc/apparmor.d/abstractions/sandbox-app-launcher#L43

More on rlimit rules: https://manpages.debian.org/buster/apparmor/apparmor.d.5.en.html#rlimit_rules

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

Patrick · January 12, 2021, 7:04am

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 · January 12, 2021, 7:32am

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

to

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

?

Patrick · January 12, 2021, 7:33am

That does not work. Same error.

Patrick · January 12, 2021, 7:35am

Patrick · January 12, 2021, 7:42am

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 · January 12, 2021, 8:24am

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 · January 17, 2021, 2:01am

That’s not the issue. We don’t depend on a preexisting /etc/machine-id. We use https://github.com/Whonix/sandbox-app-launcher/blob/master/usr/share/sandbox-app-launcher/machine-id 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.

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? 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 · January 17, 2021, 3:40am

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 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?