On Fri, Jul 19, 2019 at 1:21 PM Chris Laprise <[email protected]> wrote: > > On 7/19/19 10:13 AM, Daniel Moerner wrote: > > Thank you, this is a great tool. Everything is working perfectly as far > > as I can tell. It also works with fish shell by adding .config/fish to > > $chdirs. > > > > I was thinking about what kinds of files, not present in the default > > installation but possibly added to a user's system, might need to be > > added to $chdirs and $chfiles manually. Perhaps such a list could go in > > the documentation. Some examples: > > > > 1. Any files sourced by your shell startup scripts that are in the > > persistent private volume, e.g., files that provide completion > > information for your shell but that aren't in the template. > > If you could provide a specific example, that would be great. The usual > shell sources are already included, at least the ones that get executed.
An example is the popular fuzzy finder fzf. Although this is packaged in Fedora, I had a test VM where I followed the instructions to install it as a vim plugin (https://github.com/junegunn/fzf#as-vim-plugin), which creates $HOME/.fzf.bash and appends [ -f ~/.fzf.bash ] && source ~/.fzf.bash to your bashrc. If you then enable qubes-vm-hardening, although your bashrc is protected with chattr, it is sourcing another file that might be overwritten by a malicious user. (The contrast I'm drawing is that the Fedora package's completion files in /usr/share/fzf/shell are not user-writable.) I don't think this is a case that you should expect to be able to handle automatically, given that it relies on the user adding something to their own bashrc. Once qubes-vm-hardening is installed, the user will be forced to perform extra actions to edit bashrc and so hopefully will think to also chattr +i ~/.fzf.bash, etc., if needed. It would probably only be an issue when first enabling qubes-vm-hardening in an older VM, which might have some of this stuff left over. > > > > > 2. Executables installed by other package managers that don't use the > > normal paths. For example, go uses $HOME/go/bin by default; cabal uses > > $HOME/.cabal/bin. Probably not worth trying to list all of these, but > > rather just noting the risk. Of courses, users that make regular use of > > these package managers might not want to enable this kind of hardening > > for convenience reasons. > > That is interesting about language-specific environments; these appear > to be examples that don't play nicely with the host OS or shell. My > initial advice here would be to add protection for $PATH (such as > Qubes-VM-hardening) to your template early, then add these other > components afterward. In future, it may be possible to parse the $PATH > for anything > that references the private volume, then then automatically lock those > paths down. No, they really don't play nicely, and there are real worries here, as with that recent issue with rubygems and strong_password a few weeks ago. I think the user will have to handle it themselves by editing the /usr/lib/qubes/init/vm-boot-protect.sh script, depending on their workflow. (For example, go uses $GOPATH/bin, and I believe some people keep a startup file in each project directory with a custom $GOPATH for that project which they source when working on it, leading to bin directories scattered all over and a constantly changing GOPATH and PATH. I wouldn't expect any of that to be handled automatically.) > > BTW, thank you for the bug fix! I've already posted it with a note in > the Readme. The current version is now 0.8.5. No problem! Daniel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAPSgt5%3DsQZo9k4iJpTtJqbTNbrx5kNtA1EXFNwr3q1i6HMJgHQ%40mail.gmail.com.
