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.
