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: 3, Interesting) by jmorris on Monday January 09 2017, @05:14PM
The Good:
#1. Can't argue with the First Commandment. Thou Shalt Make Backups. So many "hair on fire" problems become annoyances if you know your backup is good.
#4. Remote syslog is valuable for exactly the reason stated, the logs are the first target after an intrustion.
#17. Only install software from a trusted source. Just being in the Play or iTunes store does NOT transfer any Trust you have for Google or Apple. And to a lesser extent, this extends to the Debian and Redhat repos, not a lot of auditing happens between the original tarball and a signed binary package. The middlemen ADD risk, not subtract it. They also add easier updating and convenience, be aware of the balance and choose, not juts take the default.
#18. Yes! Only a madman trusts a phone with risky information like banking details.
#21. IF you can get a friend or relative to run Linux, i.e. they have no hard dependency on a legacy Windows app, it really does solve the problem. Just remain aware that the IF there is a killer.
#25. The big advantage of Linux with a package manager. Instead of the one app at a time updating of Windows.
The Bad:
#2. A Syncstop is overkill. Disable sync on your phone, that also slow down LEOs who want to rummage around in your phone. So set your default action to Charge Only and you aren't depending on remembering to use a special cable.
#7. Yes it would be nice to be rid of Flash. But he is simply wrong, Firefox not only still supports it but Adobe has brought the damned thing back from the grave and started updating it again. Use FlashBlock to minimize the damage it can cause.
#20. This is security theatre unless you are a terrorist, drug dealer or trading kiddie porn. And probably won't actually save you if you are doing one of those things. They will drop a sniffer in your phone if "they" are after you and few others are in a position to sniff your traffic anyway.
#26/#30 are simply retarded. HTTPS Everywhere is retarded. I do not give a shit if my traffic to wunderground.com is logged. I just don't. Why do we need to expend gigawatt hours of electricity (half of which is on battery powered devices) to encrypt traffic that doesn't need protection? When I'm streaming music I really don't care if it is encrypted anywhere along the signal path. Sorry, I just do not care. I DO care about the visible difference in battery life. WPA2 (vs open access point) adds about 1/3 to the battery drain to stream music. If another layer of encryption for https were dropped on top of that it would just cost more battery life for no gain.
#50 is bad advice. Why care about security and then let Amazon put a microphone listening 24/7 in your home? Just say no to any IoT product that ties to a cloud server outside your home.
The Ugly:
All the container bull crap. It really is just a way to try to get away with running almost entirely untrusted (and untrustworthy in most cases) code. Nobody is really auditing any of it, nobody usually really understands what is even in the damned things TO update it. Everybody ASSumes "somebody" upstream actually understands what is going on but they don't; what happens is the code monkey bangs the keyboard until it "works", it gets thrown over the wall and the monkey is retasked to something else.
SELinux is a menace because it inspires an undeserved trust in a system NOBODY understands. O'Reilly put out a book on it but everything it said was obsolete by the time I could get my hands on it. It is basically putting absolute trust in a very small cabal. The only machines that leave it enabled are very specific use servers who didn't stray far from how RedHat imagined they would be used or people who use the SE Linux Troubleshooter; and that just blindly writes an exception for every time it fails because zero people understand it enough to even make sense of the error messages.
#3. No, the auditing system is another nightmare. It makes /var/log/messages an unreadable mess. It is so bad the usual method to read that file if auditing is enabled is with grep -v audit /var/log/messages | less
(Score: 3, Informative) by maxwell demon on Monday January 09 2017, @07:56PM
https not only protects from logging, it also protects from middlemen modifying content (this may even be your ISP) [infoworld.com].
There's AFAICT no http-derived protocol that supports digital signing of cleartext (that is, the content is in the clear, but carries a cryptographic signature), therefore https is the only way to protect against such manipulation.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Monday January 09 2017, @08:25PM
#26/#30 are simply retarded. HTTPS Everywhere is retarded. I do not give a shit if my traffic to wunderground.com is logged. I just don't. Why do we need to expend gigawatt hours of electricity (half of which is on battery powered devices) to encrypt traffic that doesn't need protection?
This sounds dangerously close to the "if you don't have anything to hide, you have nothing to fear" fallacy. Even ignoring that, if you only encrypt certain traffic to specific places you draw attention to it, and it is much easier to focus resources to subverting or breaking it.
(Score: 2) by jmorris on Monday January 09 2017, @08:54PM
Let me introduce you to a concept called "risk and reward" Encrypting my streaming music brings so close to zero reward than the very high cost totally swamps it. The reward of encrypting MOST of my routine web activity is almost zero. The sites themselves are the menace to privacy, NoScript, FlashBlock, Ghostery, etc. are of far greater benefit to my privacy than what my ISP may or may not be gleaning from snooping the traffic.
I encrypt the WiFi link because I must, had a neighbor do naughty things with the open access point; can't be nice in the $current_year. But there is a public AP at work that isn't encrypted (uses a captcha login page requiring an account) so I can compare the battery drain, it is significant, as I noted. Encryption is not even close to free, the cost must be weighted against the gain. Especially when battery power enters the equation. Btw, back to that open AP, yes it would make sense to be a lot more paranoid about traffic going through a public AP.
HTTPS for gmail or even solyent is a different risk/reward calculation. Not that I'm worried about the monitoring of content here, everything I post is for public consumption, it is the loss of the login info since it is hard to do a split http/https where the login is via https and everything else http without opening up huge holes. And even with gmail I am not worried about the content of my mail, if I were it sure as Hell wouldn't be in my gmail account because Google is the big risk. No, again it is the gmail account itself that needs the protection since that one username/password gets an attacker so much. Two factor, btw, should be considered mandatory the second you put any money near your google account. Too bad evolution's calendar goes effing insane when you do.
(Score: -1, Troll) by Anonymous Coward on Monday January 09 2017, @09:55PM
You catch more flies with honey than vinegar, you know.
Or to put it in language you can understand, you don't have to be a cock, you *choose* to be a cock, then other people choose to avoid you.
(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]