Hardening Guide for Paranoid Noobs?

[Stumpy]

I was reminded about qubes hardening that Chris L has been working on
and also noticed that Patrick/Whonix is now basing whonix on thier
kicksecure distro and was trying (not so successfully) to absorb all of
this. I got the impression that Chris's work wouldnt jive so well with
kicksecure (fair enough, can just use it on non-whoinx setups) but wasnt
sure. Also there is the idea of DVM sys-* (net/usb/firewall/etc) vms
sounded like they would add an extra layer of security, maybe based on
centos (I have seen conversations about how fedora doesnt sign or
something apps in their repos? please dont troll me, i am not trying to
pretend like i understand that) and some other things that i am sure i
have missed (maybe a iptable/firewall gui [apart from whats built into
qubes settings... i just dont find that intuitive).

In short, it just seems like there are quite a few additional hardening
things that can be done but for novices like myself a step by step spoon
feeding explanation/howto that brings it all together would be awesome.
If i ever get something working I will try to document it but as its
taken me like 3 years to just get comfortable with qubes i am not
holding my breath... anyone interested in crowd funding something like
this? (*not* for me to write, more like to crowd fund for a qubes guru
to write) :P

[awokd]

Stumpy:

> I was reminded about qubes hardening that Chris L has been working on
> and also noticed that Patrick/Whonix is now basing whonix on thier
> kicksecure distro and was trying (not so successfully) to absorb all of
> this. I got the impression that Chris's work wouldnt jive so well with
> kicksecure (fair enough, can just use it on non-whoinx setups) but wasnt
> sure. Also there is the idea of DVM sys-* (net/usb/firewall/etc) vms
> sounded like they would add an extra layer of security, maybe based on
> centos (I have seen conversations about how fedora doesnt sign or
> something apps in their repos? please dont troll me, i am not trying to
> pretend like i understand that) and some other things that i am sure i
> have missed (maybe a iptable/firewall gui [apart from whats built into
> qubes settings... i just dont find that intuitive).

Just running Qubes by itself is already more hardened than 99% of people
out there, so if your main concern is standard/driveby attacks against
mainstream OSes, you shouldn't be very much so. You cover multiple points:

- There is something in the works to allow custom kernels inside AppVMs.
Whonix and others can use them for additional hardening and/or
additional drivers. Don't think it's released yet.
- Chris's VM hardening works on regular qubes. Not sure if it will on
Whonix ones.
- DVM sys-* is pretty straight-forward, just follow the docs.
- Centos is unrelated. If you're concerned about Fedora's lack of
signing, switch to Debian templates, or some other that has signing.
- Mirage can be used as a sys-firewall replacement.

--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

[Stumpy]

On 2020-09-05 13:35, 'awokd' via qubes-users wrote:
> Stumpy:
>> I was reminded about qubes hardening that Chris L has been working on
>> and also noticed that Patrick/Whonix is now basing whonix on thier
>> kicksecure distro and was trying (not so successfully) to absorb all of
>> this. I got the impression that Chris's work wouldnt jive so well with
>> kicksecure (fair enough, can just use it on non-whoinx setups) but wasnt
>> sure. Also there is the idea of DVM sys-* (net/usb/firewall/etc) vms
>> sounded like they would add an extra layer of security, maybe based on
>> centos (I have seen conversations about how fedora doesnt sign or
>> something apps in their repos? please dont troll me, i am not trying to
>> pretend like i understand that) and some other things that i am sure i
>> have missed (maybe a iptable/firewall gui [apart from whats built into
>> qubes settings... i just dont find that intuitive).
>
> Just running Qubes by itself is already more hardened than 99% of people
> out there, so if your main concern is standard/driveby attacks against
> mainstream OSes, you shouldn't be very much so.

My threat model is not super strict at home (when traveling toooootally
different scenario [lots of diff scenarios actually, will save for
another post])

> You cover multiple points:
>
> - There is something in the works to allow custom kernels inside AppVMs.
> Whonix and others can use them for additional hardening and/or
> additional drivers. Don't think it's released yet.

Nice! I wasnt aware of that, will hurry up and wait :)

> - Chris's VM hardening works on regular qubes. Not sure if it will on
> Whonix ones.

I got the impression it wouldnt but that might be moot as kicksecure
seems to be quite hardened.

> - DVM sys-* is pretty straight-forward, just follow the docs.

True enough i guess
> - Centos is unrelated.
Well I had mentioned CentOS since I thought thier packages, like RH,
were signed?

> If you're concerned about Fedora's lack of
> signing, switch to Debian templates, or some other that has signing.

So centOS doesn't sign their packages?

> - Mirage can be used as a sys-firewall replacement.

I thought about that, i ended up just going with a minimal centOS
template for my sys-* appvms.


I know there have been back and forths about Qubes "Ease of use"
especially for non-techies; I consider myself somewhere in the middle,
but I was wondering about configs during start up? I totally understand
the Qubes Team has more important (sec) things to work on but I think a
UX person was hired to address some of the UX things in Qubes which
could be polished? (not 100% sure about that, maybe i was reading about
another distro). It would just be nice if a thorough howto could bring
much of the hardening documentation together rather than skiping around
from one doc to another - or better yet make some of these things
options during the install like which "distro would you like to use for
your minimal templates", "Would you like to add X community templates",
click here to input your VPN provider info if you want a VPN proxy,
"click here if you want your sys-* to be a DVM", "select your win iso if
you want a MS win appvm, and click here if you want it to be standalone
or a template", while I am completely aware that its easier to suggest
such things than to actually do them it seems like a worthy goal for
making a more versitle and perhaps noobish friendly Qubes while also
addressing FAQ (granted not everything i listed is a requalr
mailing/forum list question) which might make those FAQs a bit less...
frequent? :)

Anyway, just my ? cents.

Cheers

[Andrew David Wong]

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

On 2020-09-05 12:35 PM, 'awokd' via qubes-users wrote:
> If you're concerned about Fedora's lack of signing, switch to
> Debian templates, or some other that has signing.

This is a misconception. Fedora packages are absolutely
cryptographically signed by PGP keys. The signature verification must
succeed, or else the package will not be updated or installed. You can
prove this for yourself by temporarily moving/renaming the signing
keys, then trying to install a package.

The real issue is about signing repo metadata. See these threads:

https://groups.google.com/g/qubes-users/c/HHedtfDFdj4/m/dap-D0nwEwAJ
https://groups.google.com/g/qubes-users/c/cNwCH3rcIGk/m/grr1yJktDAAJ
https://groups.google.com/g/qubes-users/c/X0GvIdpQtcM/m/Tey9k_geWGUJ

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl9Wt2YACgkQ203TvDlQ
MDAcSQ//Z4gXnuTfz2GyFTycvJ2wsoLdI24SbM8f6+jron8tlFEo9hcjWF4leM/d
DlvT7sVGX94XBbe8gdsYIFQbNXCknq5d4F89jDnxHLpe/vQtZ23VSBzE81yGZjTq
WU1fCclQD3pMhASYna8u4o+TcYe3RfbLqSaq3HfVhtFMsYXaZLp6MKbVAWtLcXXz
VeBAnOft/E7HJeBtZQQj66zgsbdzjKvcm8ot+dE/VrTZ8ohX+P6uXca04G2Z4G90
oyRgpIFr4u+3EORNap7R2Cr44U7WZBI4Wv9bcXkZZcC4yxSetD1hYkl9bhC8a8GV
iJhFu/Y5Utowfj3IeXb17Bt724YeNhTJUO9hGrN4W16+XmIPmF7Vy2yNS196NipQ
NkW6dXw7CDDLjBFMr+Uv5S1sjCGT1TVGLolfkZt4MlAeGlNYw8gjnVQx7fzE7Vnf
RRE4ckPmtJRf1FU3/ONaowhQ/RCxakJqF3CSoaf7+Wg++mqu02/jm5d/0AMrB7Ib
/iVm1Ztc1DAqe7GGMQGl2uWAGFg6RuEmgxWInwFnuCzOm/LId2bRI2PI52PQAEJl
A+F4MbhuiHeG4WRMZOKCwRZgHaNGE8Zk3wj9q9BE5dAPm/+OWpc6GmKnRfckBxwo
8ZEzgOkBgkmd0WMGjMQGXlvosj4irRtycUpUi+ByWSHzRNqF/MU=
=eHe6
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

On 2020-09-07 5:42 PM, Andrew David Wong wrote:
>
> On 2020-09-05 12:35 PM, 'awokd' via qubes-users wrote:
>> If you're concerned about Fedora's lack of signing, switch to
>> Debian templates, or some other that has signing.
>
> This is a misconception. Fedora packages are absolutely
> cryptographically signed by PGP keys. The signature verification must
> succeed, or else the package will not be updated or installed. You can
> prove this for yourself by temporarily moving/renaming the signing
> keys, then trying to install a package.
>
> The real issue is about signing repo metadata. See these threads:
>
> https://groups.google.com/g/qubes-users/c/HHedtfDFdj4/m/dap-D0nwEwAJ
> https://groups.google.com/g/qubes-users/c/cNwCH3rcIGk/m/grr1yJktDAAJ
> https://groups.google.com/g/qubes-users/c/X0GvIdpQtcM/m/Tey9k_geWGUJ
>

Follow-up:

https://github.com/QubesOS/qubes-issues/issues/1919#issuecomment-689245921

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl9YM6AACgkQ203TvDlQ
MDA/RxAAwi0TYbqNgyuaJpEpY/lX6UhxVbDPyexrl3ao2ycRTeIXCKguLimjLIT9
o9QARbQTfCdHR0GdAGIE+f3q86HDnF+WIeUCUJuV0WRYI9JcrmgOXFxcBACpw2qI
FmRC7JyqGvLg+hE3lPQUFtdNgnK6/Xxp4s0QrlJEr9UjXCv6UAQ5SVe3cxwVFWi2
PIHRqaxWIUauVMUIkrrBEWhcaoRVJgWNIAkepF3ScjaHkojnDBdPJ2Df5ckC34Rg
aAUoRFSbRnxGyQdekkXQP1XMKb7Hmf21p8FR6TiUVI46TfrTgF5xeG8U1cmV2K5F
P+b4rty2sVOVOT47hq0EIBgAkeBBQXMNJ4ebeGyju2o1vc0kcgIjbQvBYXevMZvW
SPP+yKIQQ9GfP3Nr4pPab/3JX0sZivdT1xPVeV/BQxU9Xc4X3N5gYqpJKJxEjHtO
JWK6HPn0JsX3uyC4UBGpLrwLvyyzKuxcyf3JiIl26xDORTIFu62oa16Guo/2Pee3
LdQcXEQ1K3ZtfetppCisdrjuKiXmN+hZG8PnIsAoro4NWW6VkUTixFSzU37ykMb7
1/H8E8OKXXCGDyXbMU84A+G5LvFc0PQkZxtPGTZ1mw8juXdtpSEGwWeReCeH4fY1
Z6cQf5JHfSI8ypw6dwBLoyzROEsReHa2CwAH/XtybhV6Rq7zjwQ=
=7itL
-----END PGP SIGNATURE-----

[Ulrich Windl]

On 9/9/20 3:45 AM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2020-09-07 5:42 PM, Andrew David Wong wrote:
>>
>> On 2020-09-05 12:35 PM, 'awokd' via qubes-users wrote:
>>> If you're concerned about Fedora's lack of signing, switch to
>>> Debian templates, or some other that has signing.
>>
>> This is a misconception. Fedora packages are absolutely
>> cryptographically signed by PGP keys. The signature verification must
>> succeed, or else the package will not be updated or installed. You can
>> prove this for yourself by temporarily moving/renaming the signing
>> keys, then trying to install a package.
>>
>> The real issue is about signing repo metadata. See these threads:
>>
>> https://groups.google.com/g/qubes-users/c/HHedtfDFdj4/m/dap-D0nwEwAJ
>> https://groups.google.com/g/qubes-users/c/cNwCH3rcIGk/m/grr1yJktDAAJ
>> https://groups.google.com/g/qubes-users/c/X0GvIdpQtcM/m/Tey9k_geWGUJ
>>
>
> Follow-up:
>
> https://github.com/QubesOS/qubes-issues/issues/1919#issuecomment-689245921

Being a long-time SUSE user, I'm somewhat surprised, assuming that
Redhat and SUSE would use a similar mechanism.
For SUSE the metadata root (metadata files, their sizes and their
checksums) is signed. see
https://en.opensuse.org/openSUSE:Libzypp_metadata_signature

[lama...@gmail.com]

For the Whonix VM's, you can enable AppArmor by just changing the kernel parameters in the Qube settings.

https://www.whonix.org/wiki/Qubes/AppArmor

For more VM hardening, you can install Linux Kernel Runtime Guard(LKRG).

For Whonix and Debian VM's, this is made real easy by Whonix(note that Whonix recommends using a VM kernel, but for me it works fine with the default kernel supplied by dom0):

https://www.whonix.org/wiki/Linux_Kernel_Runtime_Guard_LKRG
More instructions:
https://bitbucket.org/Adam_pi3/lkrg-main/src/master/README