Protect AppVM init startup scripts:

[Chris Laprise]

Here is a small script for Linux templates that protects files executed
on startup by...

bash
sh
Gnome
KDE
Xfce
X11

Together with enabling sudo authentication, this is a simple way to make
template-based VMs less hospitable to malware.

LINK: https://github.com/tasket/Qubes-VM-hardening

--

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

[cooloutac]

ok you convinced me I have to enable sudo now. lol

[Chris Laprise]

I should mention this approach for /home init scripts does also help
standalone Linux VMs.

There is an update in the works that can knock-out even some root-user
(privilege escalation) malware, though this addition would not help
standalones. The technique is to erase-or-replace dirs like /rw/config
at boot time.

The overall result should be that an attacked VM (especially
template-based) has a better chance of malware being in a
dormant/disabled state when the VM is started. And the price in users'
time/energy for gaining this margin of security should be quite low.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-04-10 08:43, Chris Laprise wrote:
> Here is a small script for Linux templates that protects files
> executed on startup by...
>
> bash sh Gnome KDE Xfce X11
>
> Together with enabling sudo authentication, this is a simple way to
> make template-based VMs less hospitable to malware.
>
> LINK: https://github.com/tasket/Qubes-VM-hardening
>

Looks great, thanks!

Issue: https://github.com/QubesOS/qubes-issues/issues/2748
CDFT: https://www.qubes-os.org/qubes-issues/#qubes-vm-hardening

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY9AGeAAoJENtN07w5UDAw7C8P/1Spas/Knt0MxGk7cD0Ld90k
SSrgcd25AZhBgvmkxVZo5RqoczFzGMp+wVkrGSoLRUjQ26xikzvNrIB4+DSUOK44
f/pWjeyUWj3rqXHK/2rfNWJBYuFN5RetQD6zNK+6+QrARZi9MWnP/ii38WG2A57v
fAMYmGLDE9e1OClYRKLrymLdbgFn/O5ioULKX0qFtd/iln+qPIhBZxzaUsm2COgb
i46oqX3WvAQkcqL9MJ/0hWKvoShr5r9DG3/BScCsZxByVg76YB7iigCrCkJtC1gI
jdV3Dy/7oiKHsJsV1A8TL/7y7OCGtrIDQk8P3gIbCbCkf6bq0FFbcq/IZxiVpf7Y
Lx6xDXtZfJcGxbCIorft4f8aQjSgwbzP7gKUi13mxQjGGCZWusR5CHeUqxlqvtII
G0ojdH+GAUjH9GP86NFs25zv6kHy7rkW7FPYqyn+T9UNolpgUokFvJ85Cb/xQe42
SRGSrGNP5udwQ/MqdW3qdgzkZiezLNHZdlFLtM39ni5I0Okk9ga3OEYhp8dd3rOs
i+Gg557mW5D+Vtliir1QvJKijEWZk3bVWuwSfUSS2PUXFKwvxKvBbt1fuhmxxt95
u3ryfSAbx/4iRIcFs8PYEVMO1nDkS616a9qbGXW38vsU+6M8/JWX9KfUgPAC+Vrn
5kWgLvAqb9KXBDtenikt
=Z3KN
-----END PGP SIGNATURE-----

[Chris Laprise]

On 04/10/2017 11:43 AM, Chris Laprise wrote:
> Here is a small script for Linux templates that protects files executed
> on startup by...
>
> bash
> sh
> Gnome
> KDE
> Xfce
> X11
>
> Together with enabling sudo authentication, this is a simple way to make
> template-based VMs less hospitable to malware.

Testing a new version that can also remove scripts/malware in
/rw/config, etc...

https://github.com/tasket/Qubes-VM-hardening/tree/systemd

[tom...@gmail.com]

Suggestion: Instead of having "VMs that boot 'cleanly'" I'd propose to add following option:

- configuration data that lives in /rw/config (usrlocal) and is cleaned by this scripts/services to be fetched from Dom0 (or dedicated VM) based on VM's name.

This should be done after cleanup service and before Qubes code that executes /rw/config/rc.local (or sets firewall rules).

Purpose is to keep current (original 3.2) configuration behavior, while ensuring configuration is not modifiable by malware, neither getting 'clean boot'.

What do you think?

[Chris Laprise]

This would hinge on what "configuration data" means. IMO, most of that
in /rw consists of executables or binds... stuff that shouldn't be left
in place when the VM in question is considered at-risk.

The part about dom0 seems unnecessary. The protection service is running
from the template's read-only root, before /rw is mounted.

To "clean" /rw contents... it doesn't seem healthy to do this in a
conventional sense with parsing. It should perform removal/replacement
of files, which is already done in some sense. Going forward, it could
make exceptions for things like NetworkManager connections and Tor data
(if their formats allow no execute/scripting directives) based on a
whitelist. But for now, 'clean boot' is a usable compromise that keeps
/home data.

The latest version of the protection service does its job before the
/rw/config scripts (and bind-dirs), BTW. Another thing is that it can
'clean' (replace) any file in /rw, /home or otherwise if you add the
path+file to the /etc/defaults/vms folder in the template.