On Fri, Jul 19, 2019 at 1:21 PM Chris Laprise 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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/CAPSgt5%3DsQZo9k4iJpTtJqbTNbrx5kNtA1EXFNwr3q1i6HMJgHQ%40mail.gmail.com.
