The modified PATH would also need to apply for invocations through sudo. Fortunately sudo has a setting secure_path.
madaidan via Whonix Forum:
I don’t see why it would cause apparmor issues.
Suppose git internally used gpg. Using standard PATH search to find the gpg binary. git simply calling “gpg” not “/usr/bin/gpg”. Then later an apparmor profile is added for git. By modifying the PATH variable and having gpg in any other path then the default “/usr/bin/gpg” could result in an apparmor violation.
Or perhaps Tor Browser or Firefox would call other binaries. Dunno yet any specific examples.
Perhaps an AppArmor /etc/apparmor.d/tunables/... or so drop-in configuration snippet could solve that.
No, you can stack commands with a single ${wrapper_pre}. See the example above in which torsocks and firejail are both used for gpg.
If you want multiple drop-in config files,
Yes. For sure.
Each application that provides a wrapper would provide a configuration snippet. Otherwise it would be very inflexible - not using any component (for testing, Kicksecure, alternatives, whatever) no longer possible - at least not without separate user changes to wrapper configs which is bad usability.
we can modify the script to source ${sw_dir}/${program_name}_{0..9}.conf. So for example, to stack torsocks and firejail using multiple config files you can create /etc/wrapper.d/gpg_0.conf and add:
wrapper_pre+="torsocks"
Maybe needs to add a space before or behind.
This might be good enough for an initial implementation but would break on more complex inputs perhaps including single quotes, double quotes or command line parameters that contain spaces.
Instead of setting variables directly with wrapper_pre+= perhaps better to use a shell function because then constructing the actual variable could be done in a shell function (later fixes for white spaces etc) and wouldn’t require later config file changes.
/usr/lib/pbuilder/pdebuild-checkparams uses
DEBBUILDOPTS="${2:+$DEBBUILDOPTS $2}";
EXTRA_CONFIGFILE[${#EXTRA_CONFIGFILE[@]}]="$2";
/usr/lib/pbuilder/pbuilder-modules
function get_source_options() {
local source_options
local arg
# Split and de-escape DEBBUILDOPTS. Can't iterate over it before
# de-escaping, as word splitting does not take quotes in the variable into
# account. Need eval as $(echo $DEBBUILDOPTS) on its own doesn't perform
# quote expansion, since quote expansion operates on the *original* word.
eval local args=($DEBBUILDOPTS)
for arg in "${args[@]}"; do
Not sure yet but proper handling for quotes, any special characters and white spaces will probably require a bash array. I don’t know any bash scripts as role models from top of my head.
then create /etc/wrapper.d/gpg_1.conf and add
I am not sure yet if the name of the program to be wrapped should be part of the configuration file name. Might work. What is the advantage of this? What would be the disadvantage of having the name or path of the to be wrapped application defined in the config file?
What do you think about uwt (/etc/uwt.d/30_uwt_default.conf) syntax
uwtwrapper["/usr/bin/git"]="1"
?
/etc/wrapper.d/gpg_1.conf would mean the first thing that would be run if someone used Debian standard PATH and would execute gpg? Dunno if /path/to/uncommon/location should be supported.
