On Fri, May 20, 2016 at 11:57:32AM +0000, 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
