SoylentNews is people
SoylentNews
Red Hat employee Daniel J. Walsh writes via OpenSource.com
When I was young, Paul Simon released his hit song, 50 Ways to Leave Your Lover. Inspired by this song, I've collected 50 ways sysadmins and laypeople can avoid getting hacked:
"Make a new plan, Stan"
[...]
6. Run applications in the SELinux Sandbox whenever possible--it was a container before containers were cool. Also follow the development of Flatpack, which soon should be developing sandboxing capabilities.7. Don't install or use Flash. Firefox no longer supports it, and hopefully most web servers are moving away from it.
[...]
"Just get yourself free"
[...]
19. [...] I don't do online banking on my phone--only on my Linux computer.
[...]
"Hop on the bus, Gus"21. Run Linux on your systems. When I first hooked my father up with a computer system, I barely got home before his system was infested with viruses. I returned and installed Linux on his system and he has been running it ever since.
[...]
"And get yourself free"
[...]
50. Set up a special guest network for all those Christmas IoT devices your kids receive. I love my Amazon Echo and automated lights and power switches ("Alexa, turn on the Christmas Lights"), but each one of these is a Linux operating system [whose manufacturer's configuration] has questionable security.
Do you take exception with anything he suggests. (Being a Red Hat guy, he is enthusiastic about systemd.) Can you think of something he missed?
(Score: 1) by Burz on Monday January 09 2017, @10:36PM
This all proves that you can't get excellent security from a large, monolithic kernel like Linux. Security features share context with (way) too many other features.
Qubes OS bases its security on Xen, a 1MB hypervisor that runs on bare metal.
The (risky) NIC and USB controllers are isolated inside service VMs (like virtual routers) via the IOMMU, along with almost everything else. App-level activities and data are also partitioned by the user--isolated from each other.
The parts of a Qubes system that remain privileged are...
1. CPU + memory
2. keyboard (preferably PS/2)
3. graphics
4. the VM that runs the GUI (app window content is unprivileged, via an isolated X layer)
The main disk controller is also privileged, though this is due to change in the future (it is not a priority for isolation because it is considered both an internal and non-networked component).
The upsides are:
* A GUI that always keeps security context in view: VM windows are labeled and colored.
* A class of threat models that does not drive the user crazy: If a relatively untrusted VM becomes compromised, the threat is very well contained. And if malware finds a viable priv escalation in Linux or Windows, its pretty certain not to reach your core system or firmware.
* Graphics, keyboard and clipboard cannot be spoofed OR sniffed.
* Running Firefox or other risky apps in Disposable VMs is also made easy... the VMs disappear as soon as the app does.
* Interesting possibilities like data-sanitizing functions that carry low risk. For example, a PDF renderer can be run inside a disposable VM, which returns only raw bitmaps of very specific dimensions to the parent VM--which then assembles the bitmaps into a sanitized version of the PDF.
* Strong isolation of anon networks like Tor and I2P. Whonix can be installed as a client OS. Exploits against Tor Browser can be contained without leading to leaks or uncloaking.
* VPN proxy VMs that are basically leak-proof.... Whatever VMs you connect to them downstream won't leak (this is also true when using Whonix VMs as gateways to Tor).
Also...
Qubes VMs are usually run from OS templates: Read-only installations that can be shared by many VMs.
Anti-Evil Maid feature that uses your TPM chip to verify firmware and OS integrity.
And a very interesting (even brave) development roadmap.
https://www.qubes-os.org [qubes-os.org]