See file /etc/X11/Xsession.d/20software_rendering_in_vms.
- monero-gui in sandbox
- any other Qt based application being slow inside VMs because of this
1 Like
Also, is there any need for the full file path in the array?
We could have:
xsession_d_file_list_executable=(
"20torbrowser"
"20uwt"
...
)
for file_name in "/etc/X11/Xsession.d/${xsession_d_file_list_executable[@]}" ; do
Makes it simpler.
madaidan via Whonix Forum:
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).
1 Like
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.
1 Like
what general purpose system utilities can be integrated for DoS resistance? Are the defaults sane?
1 Like
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.
1 Like
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.
More on rlimit rules: apparmor.d(5) — apparmor — Debian buster — Debian Manpages
No, the dreaded :(){ :|:& };: can still be used to trivially wreck a system.
1 Like
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?
1 Like
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
?
1 Like
That does not work. Same error.
1 Like
1 Like
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?
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.
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?
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