This would be better than sed.
getent passwd | awk -F: '{ print $1 }'
getent passwd | cut -d: -f1
Does str_replace support wildcards? I thought it just replaced strings exactly.
No, no wildcards. Finally a simple tool for simple search/replace without regex magic. 
Most Debian packages aren’t autogenerating config files for every app on the system. I think it’d make sense to do this for sandbox-app-launcher because otherwise, there will be tons of leftover files.
I don’t think it should make much difference.
It doesn’t matter what tty it’s on if it can see the X socket (/tmp/.X11-unix).
It might be better to make sandbox-app-launcher generate the config if it’s not there?
if ! [ -f "/etc/sandbox-app-launcher/${app_name}.conf" ]; then
/usr/share/sandbox-app-launcher/setup-permissions "${app_name}"
fi
This way, it doesn’t break non-interactive stuff and it also doesn’t worsen security by assuming yes.
madaidan via Whonix Forum:
Most Debian packages aren’t autogenerating config files for every app on the system. I think it’d make sense to do this for sandbox-app-launcher because otherwise, there will be tons of leftover files.
I guess best compromise is “apt remove” not remove config files but “apt
purge” remove all.
I don’t think it should make much difference.
I speculate that APT running in sandbox will not be allowed to interact
with the user’s X.
It doesn’t matter what tty it’s on if it can see the X socket (
/tmp/.X11-unix).
When user is ruining “apt dist-upgrade” in virtual console tty1 while X
is unattended (tty7) it would be weird. apt started from tty1 would
result from popping up a GUI in tty7.
It might be better to make sandbox-app-launcher generate the config if it’s not there?
I don’t understand how that would be useful yet. Generate config with
“all yes” versus sandbox-app-launcher script internally assume “if there
is no config file, assume all yes” seems functionally be the same.
Trying to imagine future discussions / support requests. User asks
“which applications are covered by sandbox-app-launcher?” then indeed
these auto generated “all yes” config files would have a point.
“What are sandbox-app-launcher for applications in?” → “Review your
files in /etc/sandbox-app-launcher/ folder.” → Nothing there. Not great.
if ! [ -f "/etc/sandbox-app-launcher/${app_name}.conf" ]; then /usr/share/sandbox-app-launcher/setup-permissions "${app_name}" fi
Given my thoughts above, makes sense.
One thing: an autogenerated /etc/sandbox-app-launcher/${app_name}.conf
should indicate that it’s, well, autogenerated. Should add appropriate
comment. Also settings files chose by user and generated by config
script should point that out in comments accordingly.
This way, it doesn’t break non-interactive stuff
I wasn’t worried about non-interactive stuff as “no config = assume all
yes” would be simple to implement.
and it also doesn’t worsen security by assuming yes.
Yeah, functionally the same.
Could you please replace sed with cut -d ":" -f 1?
Awesome! Btw, reason: sed is a programming language and it’s not sandboxed by default. There shouldn’t be weird characters inside getent passwd but better to safe just in case.
I doubt this will have any real world advantage but it’s good just in case. -fstack-protector in general is quite weak (it only prevents linear overflows) and I doubt the program will have exploitable bugs that’d be prevented by it.
Have you seen Remove uneeded / by madaidan · Pull Request #40 · Kicksecure/sandbox-app-launcher · GitHub?
No. Totally missed. Please post links here. Useful:
What would be the best way to add Tor Browser support? It’s tricky due to the way the Tor Browser is meant to be used. What about adding code to tb-starter, similar to firejail?
Was merged. Only in developers repository for now. I am wondering since this package isn’t installed by default if I should expedite upload to all repositories (including stable). (Similar to how I did with apparmor-profile-everything for the time being it under development not recommended yet for end users.)
Dunno yet.
That is certainly an option. Once I see the source code required for starting Tor Browser under sandboxed-app-launcher I can probably discuss more where to place it best.
Could be something like:
[ -n "$tb_sandbox_bin" ] || tb_sandbox_bin="sandbox-app-launcher"
...
elif [ "${tb_sandbox}" = "true" ]; then
temp="$tb_sandbox_bin $tb_starter_bin_pre $tb_starter_bin --allow-remote $tb_starter_bin_post "$@""
$tb_sandbox_bin $tb_starter_bin_pre $tb_starter_bin --allow-remote $tb_starter_bin_post "$@" || { tb_exit_code="$?" ; true; };
...
But that would require modifying sandbox-app-launcher to not require the file to be in $PATH which would then mean we’d need to find another way to sort out the wrappers used for AppArmor enforcement.
The wrappers definitely aren’t ideal but I’m not aware of any other way to enforce AppArmor other than aa-exec but that has its own problems.
We could add a bunch of hacky exceptions to sandbox-app-launcher for Tor Browser but that’s not ideal either. i.e. something like this to the top of the file below app_name="${1}":
if [ "${app_name}" = "/home/user/.tb/tor-browser/start-tor-browser" ]; then
torbrowser="true"
app_name="torbrowser"
tb_path="${app_path}"
fi
All the other variables will be set. The torbrowser user and home directories will be created. etc.
Then before the part where the script creates the wrappers:
if [ "${torbrowser}" = "true" ]; then
app_path="${tb_path}"
fi
so the wrapper would contain:
#!/bin/bash
dbus-launch
/home/user/.tb/tor-browser/start-tor-browser
Which might work?
Hard one. We can consider various principles to guide this. Some might conflict with each other.
Since we don’t have any other way to sort out wrappers, I guess this means rather no.
Doesn’t look too bad.
Did you try to imagine another options… This… Might wrapper around sandbox-app-launcher help? Keep sandbox-app-launcher reasonable “clean” and without exceptions but allow certain environment variables to be overwritten by the calling program. Then sandboxed-torbrowser could do just that - set the required environment variables. But maybe not big advantage over modifying /usr/bin/torbrowser instead which could also set environment variables which are then honored by sandbox-app-launcher.
What would be a nice bonus would be the ability to run a manually installed Tor Browser in any folder using sandbox-app-launcher. Actually not only Tor Browser. Any binary in any folder. But that might make the code unclean and therefore not worth it.
Please implement as you see fit.
That would be a good idea. sandbox-app-launcher in its current state isn’t very robust.
I tried implementing this but realized more vital issues.
The Tor Browser files residing in /home/user are incompatible with the sandbox model. We’d need to add a bunch of holes to the bubblewrap and apparmor profiles and get rid of the separate users just to be able to execute it.
Instead of butchering the security model, we should consider replacing the Tor Browser again or make sandbox-app-launcher/tb-starter reinstall the Tor Browser in the sandbox-torbrowser user’s home directory.
madaidan via Whonix Forum:
Merged.