ANN: Qubes-VM-hardening v0.8.4 released

[Chris Laprise]

Description:
------------

Qubes-VM-hardening

Leverage Qubes template non-persistence to fend off malware at VM
startup: Lock-down, quarantine and check contents of /rw private storage
that affect the execution environment.

* Acts at VM startup before private volume /rw mounts
* User: Protect /home desktop & shell startup executables
* Root: Quarantine all /rw configs & scripts, with whitelisting
* Re-deploy custom or default files to /rw on each boot
* SHA256 hash checking against unwanted changes
* Provides rescue shell on error or request
* Works with template-based AppVMs, sys-net and sys-vpn

Version 0.8.4 expands protection to the /home/user systemd directory,
and now hides its vms config directory on all VM startups (not just when
its enabled). Upgrading is recommended.

Github link - https://github.com/tasket/Qubes-VM-hardening

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Daniel Moerner]

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.

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.

[Chris Laprise]

On 7/18/19 11:53 AM, Chris Laprise wrote:
> Description:
> ------------
>
> Qubes-VM-hardening
>
> Leverage Qubes template non-persistence to fend off malware at VM
> startup: Lock-down, quarantine and check contents of /rw private storage
> that affect the execution environment.
>
>    * Acts at VM startup before private volume /rw mounts
>    * User: Protect /home desktop & shell startup executables
>    * Root: Quarantine all /rw configs & scripts, with whitelisting
>    * Re-deploy custom or default files to /rw on each boot
>    * SHA256 hash checking against unwanted changes
>    * Provides rescue shell on error or request
>    * Works with template-based AppVMs, sys-net and sys-vpn

A bug fix has been posted and released as version 0.8.5. Updating is
recommended (see Notes)...

Github link - https://github.com/tasket/Qubes-VM-hardening#notes

[Chris Laprise]

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.

>
> 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.

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.

[Daniel Moerner]

On Fri, Jul 19, 2019 at 1:21 PM Chris Laprise <tas...@posteo.net> 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

[Jon deps]

On 7/18/19 3:53 PM, Chris Laprise wrote:
> Description:
> ------------
>
> Qubes-VM-hardening
>
> Leverage Qubes template non-persistence to fend off malware at VM
> startup: Lock-down, quarantine and check contents of /rw private storage
> that affect the execution environment.
>
>    * Acts at VM startup before private volume /rw mounts
>    * User: Protect /home desktop & shell startup executables
>    * Root: Quarantine all /rw configs & scripts, with whitelisting
>    * Re-deploy custom or default files to /rw on each boot
>    * SHA256 hash checking against unwanted changes
>    * Provides rescue shell on error or request
>    * Works with template-based AppVMs, sys-net and sys-vpn
>
> Version 0.8.4 expands protection to the /home/user systemd directory,
> and now hides its vms config directory on all VM startups (not just when
> its enabled). Upgrading is recommended.
>
> Github link - https://github.com/tasket/Qubes-VM-hardening
>

pardon my non-sysadmin query :


any chance of some real world examples? quite a few new terms there .

so install into Debian-9

but step 2 am already lost

eg how and where amd I "activating" vm-boot-protect in the templatevm ?

or during install there is going to appear a choice of which service to
start , then when one opens a TBAVM based on the specified Deb-9
template the protection work at that point ?


Can I install it in a fresh Deb-9 , and if its breaking things, just
delete the fresh Deb-9 template, or is it touching dom0 ?



I guess once installed there is no un-installing ?

[Chris Laprise]

On 7/27/19 8:27 PM, Jon deps wrote:
> pardon my  non-sysadmin  query :
>
>
> any chance of some real world  examples?  quite a few new terms  there .
>
> so install into Debian-9
>
> but step 2  am already lost
>
> eg how and where amd I "activating" vm-boot-protect   in the templatevm ?
>
> or during install there is going to appear a choice  of which service to
> start  , then when one opens a  TBAVM based on the specified Deb-9
> template   the protection work at that point ?

Go to the VM's Settings / Services tab, and add "vm-boot-protect" as a
service.

>
> Can I install it in a fresh Deb-9  , and if its breaking things,  just
> delete  the fresh Deb-9 template,  or  is it touching  dom0 ?

It has a second-stage installation step that changes sudo/root access
inside the template. And for that new root config to work, you have to
add a couple dom0 config lines (it shows you the dom0 lines at the end
of the install process).

If you remove the altered Deb-9, the dom0 config lines will stay unless
you change them back. However, in practice there is really no impact on
your unmodified templates, so whether or not to remove the dom0 lines is
a question of tidiness.

As an alternative, per the Readme step 3, you can sidestep the whole
sudo auth reconfiguration.

>
> I guess once installed there is no un-installing ?

Currently there is no "purge everything" function or uninstall. You can
remove the service manually by deleting the following:

/lib/systemd/system/vm-boot-protect.service
/usr/lib/qubes/init/vm-boot-protect.sh
/etc/default/vms

[Jon deps]

I just ended up using vm-boot-protect-root for the sys-net and
sys-usb in qube settings services

per the "Where to use basic examples"

and vm-boot-protect for regular appVMs


think I'll skip it for anything else

sys-net is working (I am using fedora-30: because of the past clock sync
issue) otherwise Deb-9 but just curious what the "additional
networks VMs would be here" proxyVPNVMs ?

"The sys-net VM should work 'out of the box' with the
vm-boot-protect-root service via the included whitelist file. Additional
network VMs may require configuration, such as cp sys-net.whitelist
sys-net2.whitelist."


PS: the appVMs seem a bit slower to boot, but could be my imagination ? :)

[Jon deps]

as expected, since my sys-net was not based on the template I installed
the script to ....

I installed it to a deb-9-clone and the disp-qubes-manager method
seems to be failing to update so typically when that happens I go to
a terminal in the template and do it manually usually it seems to
want -dist-upgrade , which presumably the disp-update has issues
with but after installing the script *

in the deb-9 template
$sudo apt-get update

fails with what looks like a script of having entered it incorrectly 3
times

so sorry, but am I supposed to add vm-protect-root to the template
services as well or how to fix this ?


hence, my original query about 'examples' thanks in advance

[Chris Laprise]

'vm-protect-root' doesn't match any service created by Qubes-VM-hardening.

Adding vm-boot-protect or vm-boot-protect-root to the services of the
template is optional. You can use either one, but it will always behave
like plain vm-boot-protect in the template (the -root functions don't
make sense in templates).

I'm not clear on when/where you're using fedora-30. Note that install
step 3 is different for fedora.

With debian-9, if you're getting immediate errors from every 'sudo'
command, this would be expected if you chose to uninstall
'qubes-core-agent-passwordless-root' in install step 3 (this means no
more sudo!). But if you chose to auto-configure sudo, you will still
need to add the config lines to dom0 for sudo to work correctly
(otherwise, sudo will just give you errors); these lines are printed in
the shell at the end of the install process.

>
> hence, my original query about  'examples'    thanks in advance
>

Not sure what example you're looking for. In debian, the installer asks
you one question: 'Configure sudo authentication prompt now? (y/n)'.

After installing Qubes-VM-hardening with sudo auth configured, running a
command like 'sudo apt-get update' will cause a dom0 auth prompt window
to appear, at which point you can hit 'Enter' or click 'OK'. Then the
command will run normally.

At the vm-boot-protect level, you should see 'bin' automatically added
to your home dir, and doing an 'lsattr -a' will show a number of
files/dirs in home with the 'i' flag set.

At vm-boot-protect-root level, you should see a new dir
'/rw/vm-boot-protect' and it should contain 'BAK' and/or 'ORIG' versions
of config, bind-dirs and usrlocal.

[Jon deps]

1)
So, I chose 'yes' at the end of the script, for 'configure sudo
authentication prompt.
a) somehow I missed the 'several commands' to manually configure
in dom0 ; could you please tell me what they are ?
b) otherwise I guess I can try uninstalling -paswordless-root from
the debian-9 template




2) please disregard what I said about Fedora, my mistype of
'vm-protect-etc", and my 1st status report, when I was still trying
things out.

3) so no service needs to be added to either the Deb-9 template, NOR any
AppVMs based on the template?
a) installing howto says to "specify one of the services for your VMs"

4) Seems that it also breaks any appVMs using other Templates where the
script wasn't installed

so think I'm close to reinstalling rather than removing the 3 lines
from dom0 referenced in your previous ; as sys-net is not working based
on a different template :) regards

[Chris Laprise]

I wouldn't do the uninstall on top of the sudo reconfig (though you
might get an interesting result...).

The text printed at the end of install:

Done.

Next.... Enable auth prompts in dom0 with the following commands:
[user@dom0 ~]$ sudo su -
[root@dom0 /]# echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
[root@dom0 /]# echo "\$anyvm dom0 ask,default_target=dom0" \
>/etc/qubes-rpc/policy/qubes.VMAuth


These are the same dom0 changes described in the doc page:
https://www.qubes-os.org/doc/vm-sudo/

BTW, if you don't remember seeing the dom0 instructions then something
might have gone wrong in the installer.

>
>
> 2) please disregard what I said about Fedora, my mistype of
> 'vm-protect-etc", and my 1st status report, when I was still trying
> things out.
>
> 3) so no service needs to be added to either the Deb-9 template, NOR any
> AppVMs  based on the template?
>     a) installing howto says to "specify one of the services for your VMs"

I didn't say that. I said that specifying the Qubes services isn't
necessary for the template; it doesn't affect whether or not the
template-based VMs use those services.

>
> 4) Seems that it also breaks any appVMs using other  Templates where the
> script wasn't installed

No, it wouldn't do that.

>
>     so think I'm close to reinstalling  rather than  removing the  3
> lines from dom0  referenced in your previous ; as sys-net is not working
> based on a different template  :)   regards

[Jon deps]

++ OK actually now I recall the lines, seems I had Not enter the 3rd
line accurately

> These are the same dom0 changes described in the doc page:
> https://www.qubes-os.org/doc/vm-sudo/
>
> BTW, if you don't remember seeing the dom0 instructions then something
> might have gone wrong in the installer.
>
>>
>>
>> 2) please disregard what I said about Fedora, my mistype of
>> 'vm-protect-etc", and my 1st status report, when I was still trying
>> things out.
>>
>> 3) so no service needs to be added to either the Deb-9 template, NOR
>> any AppVMs  based on the template?
>>      a) installing howto says to "specify one of the services for your
>> VMs"
>
> I didn't say that. I said that specifying the Qubes services isn't
> necessary for the template; it doesn't affect whether or not the
> template-based VMs use those services.
>
>>
>> 4) Seems that it also breaks any appVMs using other  Templates where
>> the script wasn't installed
>
> No, it wouldn't do that.

++so does this mean that the VMHardening must be installed in all
template VMs that will be used ? ( and if that were the case then one
would not be able to use both Fed-30 and Deb-9 on the machine, secondary
to the step 3 variance in methods to remove passwordless root ?


++further is it the case that ANY appVM must add at least the
vm-boot-protect as a service to start ; eg. sys-vpn sys-firewall
sys-whonix anon-whonix
+ its Just your saying in your write up that the vm-boot-protect-ROOT
may/may not work in those
+ but again don't expect any appVM to work w/o the VMBP service
present, nor any appVM *not using the template where QVMH has been
installed ?


ATM: per the howto, I've no manually started service in the VMBP Deb-9
Template , however

re:

"The sys-net VM should work 'out of the box' with the
vm-boot-protect-root service via the included whitelist file. Additional
network VMs may require configuration, such as cp sys-net.whitelist
sys-net2.whitelist."

I engaged the VMBP-root in the sys-net restarted, have it connected by
ETH cable on a Thinkpad T5xx-series but no internet

I did in default/vms sys-net.whitelist and did the cp command as
above then re-ran the install script as sh ./install in deb-9
template closed deb-9 and restarted sys-net


ethernet now works! *BUT importantly for a laptop not the wifi (which
worked fine pre_VMBP)

lastly, I can update deb-9 template via the default-mgmt-dvm widget,
but not directly in the deb-9 xterm via apt-get update, is that too
be expected ? as I was saying, seems to me, there are times, when one
needs to apt-get dist-upgrade that the DVM widget doesn't do




PS:
---
I seemed to have gotten it closer in sys-usb using VMBP (no -root) on
starting the AppVM I see a popup window saying :

FIRST BOOT volume initialization Please Restart

private volume is located at /dev/badxvdb

which appears to be the last bulletpoint on your github writeup,
however restarting the sys-usb does not fix , see the same popup window.

I removed my usb mouse dongle, and the error message changed to
Mount failed: BAD private volume!

so looks to break the auto-mounting of the usb mouse to sys-usb so at
root@dom0 and user@dom0 I tried

qvm-usb attach sys-usb sys-usb:1-1.2

but device attach failed:
---



so thx for tool, support, think this is for folks whom know how to use
linux :)