Bug#822693: stackable wrappers convention proposal
Could you please provide feedback for this stackable wrappers proposal? * https://github.com/Whonix/proposals/blob/master/634-stackable-wrappers.txt * https://phabricator.whonix.org/T634 Kind regards, Patrick
Bug#822693:
The user amending PATH is not great as this would be ignored by (background) applications running other applications. For example update-flashplugin-nonfree run by postinst would use /usr/bin/gpg rather than /use/local/bin/gpg because it will not have the same PATH setting as the user. Etc. > Though it would behave differently than expected when the tool is not installed (launching firejail instead of erroring with "No such file ..."). The wrappers could just be minimal scripts that would redirect to the main wrapper. And the main wrapper could would emulate acting as expected if the tool is not installed. firejail + binary installed: -> start firejailed binary firejail + binary not installed: -> not use firejail and just act as if there was no wrapper. Example /usr/local/bin/gpg would do... exec /usr/bin/gpg "$@" uwt ( https://github.com/Whonix/uwt ) wrappers act like this. (Additionally, it is handling command-not-found.) I am not sure that is a perfect solution yet. It would not cover stackable wrappers. I.e. I would not know yet how to automatically add torsocks (uwt) as well as firejail at the same time. Perhaps a generic stackable wrapper mechanism is required? Perhaps this is a bigger, general discussion for debian-devel?
Bug#822693: Safe Defaults / Automatic Protection
On Sat, May 21, 2016 at 12:59:07AM +0200, Reiner Herrmann wrote: > > Manually running firecfg also does not work for software that has profiles > > but where the package gets installed by the user after firejail was > > installed. I speculate for reasons of cleanness, it does not be create > > symlinks for binaries that are not yet installed in preparation that it may > > one day be installed. > > I think another reason is that firecfg can't know where the binary will > eventually be installed (/sbin, /usr/bin, /usr/games, ...). Sorry, ignore this. I confused the symlink destination. Symlinking all known profiles to /usr/bin/firejail would indeed be possible. Though it would behave differently than expected when the tool is not installed (launching firejail instead of erroring with "No such file ..."). signature.asc Description: Digital signature
Bug#822693: Safe Defaults / Automatic Protection
On Fri, May 20, 2016 at 11:57:32AM +, ban...@openmailbox.org wrote: > While firecfg handles symlinks well and per package hacks to create symlinks > are no longer necessary, it still needs a way to make it seamless and > automatically protect users. There is already precedent in Debian for > automatic protection should a security application be installed: > > "Please automatically enable AppArmor when the userspace tools are > installed" > https://bugs.debian.org/702030 > > The only clean way to implement this is a dpkg trigger. Run firecfg - if > some option is set in a .d config filder - each time something is installed > to /usr/bin/, /sbin or perhaps best even / (therefore running it every time > during apt-get). Otherwise there will always be inconsistencies about > whether an installed firejail, and profile, and a "to be contained" binary > is installed at the same time will result in using firejail. A state where > sometimes things work for some users but not for all is quite horrible. Hm, the problem with this approach is that packages are not allowed to modify /usr/local(/bin) on their own, so firecfg can't be called by a dpkg trigger. Placing the symlinks somewhere else (like /usr/lib/firejail/) with dpkg triggers would work, but the user would have to amend PATH (as currently only /usr/local/bin comes before the other binary paths), though this would be a one-time configuration. > Manually running firecfg also does not work for software that has profiles > but where the package gets installed by the user after firejail was > installed. I speculate for reasons of cleanness, it does not be create > symlinks for binaries that are not yet installed in preparation that it may > one day be installed. I think another reason is that firecfg can't know where the binary will eventually be installed (/sbin, /usr/bin, /usr/games, ...). signature.asc Description: Digital signature
Bug#822693: Safe Defaults / Automatic Protection
I've given this some thought: While firecfg handles symlinks well and per package hacks to create symlinks are no longer necessary, it still needs a way to make it seamless and automatically protect users. There is already precedent in Debian for automatic protection should a security application be installed: "Please automatically enable AppArmor when the userspace tools are installed" https://bugs.debian.org/702030 The only clean way to implement this is a dpkg trigger. Run firecfg - if some option is set in a .d config filder - each time something is installed to /usr/bin/, /sbin or perhaps best even / (therefore running it every time during apt-get). Otherwise there will always be inconsistencies about whether an installed firejail, and profile, and a "to be contained" binary is installed at the same time will result in using firejail. A state where sometimes things work for some users but not for all is quite horrible. Manually running firecfg also does not work for software that has profiles but where the package gets installed by the user after firejail was installed. I speculate for reasons of cleanness, it does not be create symlinks for binaries that are not yet installed in preparation that it may one day be installed.
Bug#822693: (no subject)
Sorry my mailbox was overloaded with backlog. You're right firecfg does everything I hoped for and survives package upgrades :) However Iceweasel did not get symlinked because it was not recognized somehow so I asked netblue about it on Github.
Bug#822693: Feature Request: Automatically starting programs under firejail
Hi! Thanks for your suggestion! On Tue, Apr 26, 2016 at 06:54:07PM +0200, ban...@openmailbox.org wrote: > At the moment there is no way to make all programs start with firejail > automatically. Beginner users can't be expected to start a terminal every > time they want to launch a program. This usability problem can be a hurdle > for widespread adoption. For better usability for beginners there is a graphical frontend called 'firetools' available. > The suggestion in firejail documentation is to create a symlink between a > binary's folder and firejail but unfortunately this solution is not > maintainable on its own because package upgrades will overwrite the > symlinks. The upcoming upstream release of firejail (0.9.40) will also include a helper tool called firecfg. This will create the symlinks for you in /usr/local/bin (which comes by default before /usr/bin and /bin in PATH), and are also not touched by package management. I think this is a simple and usable way to let your programs start with firejail. Would this be also an acceptable solution for you? Kind regards, Reiner signature.asc Description: Digital signature
Bug#822693: config-package-dev available in stable
Note that config-package-dev is already available in Debian Jessie: https://packages.debian.org/jessie/devel/config-package-dev
Bug#822693: Feature Request: Automatically starting programs under firejail
Package: firejail Version: 0.9.38-1 Severity: wishlist At the moment there is no way to make all programs start with firejail automatically. Beginner users can't be expected to start a terminal every time they want to launch a program. This usability problem can be a hurdle for widespread adoption. The suggestion in firejail documentation is to create a symlink between a binary's folder and firejail but unfortunately this solution is not maintainable on its own because package upgrades will overwrite the symlinks. I propose instead for a set of (optionally enabled) dpkg wrapper scripts that rely on config-package-dev to maintain symlinks of the protected programs across package updates. config-package-dev uses the dpkg-divert operation for moving packaged files to alternative locations. https://debathena.mit.edu/config-packages/
