On 03/25/2018 08:14 PM, [email protected] wrote:
I am trying to harden my Fedora and Debian templates and was hoping for some 
basic help and commands to do the following:

How would I enable sudo authentication in a Template?

There are two ways to do this now:

1. Follow this Qubes doc to get the yes/no auth prompts for sudo:

https://www.qubes-os.org/doc/vm-sudo/#replacing-password-less-root-access-with-dom0-user-prompt

2. Remove the 'qubes-core-agent-passwordless-root' package.

This second way means that sudo no longer works for a normal user. Instead, any root access in the VM must be done from dom0 with a command like 'qvm-run -u root vmname command'.

I like the first method better because I'm used to sudo.



How would I add a service like Qubes-VM-hardening ?

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

The instructions are pretty vague - I should rewrite them soon. For now the version in the 'systemd' branch (linked above) is much more robust. You start by copying the two files (as root/sudo) to:

/lib/systemd/system/vm-sudo-protect.service
/usr/lib/qubes/init/vm-sudo-protect.sh

After you copy them set execute bit and enable the service:
$ sudo chmod +x /usr/lib/qubes/init/vm-sudo-protect.sh
$ sudo systemctl daemon-reload
$ sudo systemctl enable vm-sudo-protect.service

The final step is adding either 'vm-sudo-protect' or 'vm-sudo-protect-root' as a Qubes service to each VM you want to protect. (Qubes services are added in the VM settings window on the Services tab.) The latter offers the most protection because it prevents rootkits from running when your VM starts.



Should I enable AppArmor in a template and VM?

You can try but depending on how fresh/accurate the AppArmor profiles are, it may prevent some of your apps from running properly. A long time ago I created a custom profile for Firefox with limited success but I doubt it works with FF 57+.

AppArmor was supposed to be a way to pre-package security profiles along with apps. But it didn't work out that way and so users were left to themselves to guess what settings required changes in an app's profile whenever an app had an update.

IIRC there is a GUI app called 'firejail' that can limit Firefox and other apps in a similar way. If they are more focused on keeping their limited repertoire of apps correctly profiled then it may work better than AppArmor.

Also, Whonix keeps AppArmor profiles of Torbrowser, etc. but I don't think they enable it by default.



Any other hardening best practices?

Some people prefer to start with minimal templates as a form of 'hardening'. FWIW the regular Debian template is slightly less 'minimal' than Fedora-minimal.

Overall I recommend Debian 9 because (like almost all other distros) it has a more secure update configuration than Fedora. That's because Fedora doesn't know if an attacker is trying to hold back some packages from being updated. So just switching to Debian is a type of hardening.

There are other options that try to harden the VM kernels by patching them. My take on this is they're fraught with controversy, left unmaintained and/or difficult to install. At this point I don't think its worth it even for most Qubes users, and it may be better to wait for these features to be incorporated into the main kernel.

You can also research 'unikernels' on Qubes as a way to harden the firewall. (Again, may not be worth it for most people at this point.)

Other ways to increase safety include subscribing to a reputable VPN service and setup a VPN qube, and/or use Whonix with onion sites, and also add safety-oriented extensions to your web browser. In Firefox I recommend uBlock Origin and HTTPS Everywhere.



Thanks you in advance...I am hoping these are easy for the layperson!

V



--

Chris Laprise, [email protected]
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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 post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a1166456-7b00-8e9e-3303-cf2918aed9d7%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to