On 1/6/20 9:20 AM, gorked wrote:
Thanks for replying. I will keep what you say in mind in using Debian
when I get into a position to try out QUBES. Apparently I made a
mistake in that, I thought I read on the CentOS Forum that if I did
updates, it would receive the same security updates as Red Hat.
Perhaps Red Hat is not always the most secure? Or maybe it is that what
they really market is support, since that is what a business requires to
use Linux?
I wouldn't say CentOS security updates were any poorer than RHEL. RH
does them bc they reluctantly had to save CentOS from disbanding, even
though it is counter to their stated business model. This is one of
those "complicated history" issues.
BTW, there is a community-maintained CentOS template for Qubes.
To Morph this post a bit, being a lot of intrusions are now coming in
with the Web Browser, which Web Browser is now the recommended one for
Security? I have been using Firefox, with a lot of Addons, but I had
to turn off the Java Script to buy items online.
This is not such a worry on Qubes if you keep things in separate VMs.
But if you must worry about app-level security, I would stick with
Firefox on Debian 10 and enable AppArmor (Debian 10 normally has AA
enabled, but the Qubes configuration has an unfortunate side-effect
where the default is disabled).
To enable AppArmor on Debian VMs, you can change the 'kernelopts' VM
pref for the template to add two parameters to the default 'nopat':
[dom0]$ qvm-prefs debian-10 kernelopts 'nopat apparmor=1 security=apparmor'
This will automatically carry over to all VMs based on that template
that do not have their own customized kernelopts setting. (If a VM has a
custom kernelopts setting, you'll have to add the AA params to it manually.)
Also, Firefox is not the only program that benefits from AppArmor. IMO
its easy to do and a win-win. Philosophically, I think Qubes users and
devs should hold the point of view that while guest VM code shouldn't be
relied-on as primary defense, it is best to let the guest OS use all of
its own defenses as long as they are default or easy to enable + use.
Another thing that can improve security inside a VM is my
Qubes-VM-hardening project, which restores user-auth security in VMs
(but with yes/no prompts, not passwords) and prevents malware from
hijacking the VM startup environment...
https://github.com/tasket/Qubes-VM-hardening
A note about Whonix templates: The developer for Whonix is already
making efforts to include this kind of defense (and more). But for
AppArmor, the last time I checked you still had to turn it on yourself.
Since Whonix is based on Debian, the procedure is the same as above (use
'kernelopts' setting).
Is there a movement to create a standard about what a Web Page should
never be allowed to do, to facilitate security on the internet?
Yes, there is a movement and tech project headed by Tim Berners-Lee:
https://betanews.com/2018/09/29/tim-berners-lee-solid/
https://www.theguardian.com/technology/2019/nov/24/tim-berners-lee-unveils-global-plan-to-save-the-internet
I should also mention the I2P project, which over time has developed a
different yet comparable approach to security and privacy. Tor (and by
extension, Whonix) is also evolving into this approach but Tor's
outproxy default is a snag.
Surveillance Capitalism now rules.
--
Chris Laprise, tas...@posteo.net
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/536676a4-da0d-3570-83bc-ab31c36c3a74%40posteo.net.
