Posted on 08/26/2020 6:11:46 AM PDT by ShadowAce
Like all operating systems, Linux isn't perfectly secure. Nothing is. As security guru, Bruce Schneier said, "Security is a process, not a product." It's just that, generally speaking, Linux is more secure than its competitors. You couldn't tell that from recent headlines which harp on how insecure Linux is. But, if you take a closer look, you'll find most -- not all, but most -- of these stories are bogus.
For instance, Boothole sounded downright scary. You could get root access on any system! Oh no! Look again. The group which discovered it comes right out and says an attacker needs admin access in order for their exploit to do its dirty work.
Friends, if someone has root access to your system, you already have real trouble. Remember what I said about Linux not being perfect? Here's an example. The initial problem was real, albeit only really dangerous to an already hacked system. But several Linux distributors botched the initial fix so their systems wouldn't boot. That's bad.
Sometimes fixing something in a hurry can make matters worse and that's what happened here.
In another recent case, the FBI and NSA released a security alert about Russian malware, Drovorub. This program uses unsigned Linux kernel modules to attack systems. True, as McAfee CTO, Steve Grobman said, "The United States is a target-rich environment for potential cyber-attacks," but is production Linux run by anyone with a clue really in danger from it?
I don't think so.
First, this malware can only work on Linux distributions running the Linux 3.6.x kernel or earlier. Guess what? The Linux 3.6 kernel was released eight-years ago.
I suppose if you're still running the obsolete Red Hat Enterprise Linux (RHEL) 6 you might have to worry. Of course, the fix for signing Linux kernel modules has been available for RHEL 6 since 2012. Besides, most people are using Linux distros that are a wee bit newer than that.
In fact, let's make a little list of the top production Linux distros:
CentOS/RHEL 7 started with kernel 3.10. Debian 8 started with kernel 3.16. Ubuntu 13.04 started with kernel 3.8. SUSE Linux 12.3 started with kernel 3.7.10. All these years-old distros started life immune to this attack. All recent Linux versions are invulnerable to this malware.
But, wait! There's more. And this is the really annoying bit. Let's say you are still running the no longer supported Ubuntu 12.04, which is theoretically vulnerable. So what. As Red Hat's security team points out, "attackers [must] gain root privileges using another vulnerability before successful installation."
Once more for Linux to be compromised -- for your system to get a dose of Drovorub -- your system already had to be completely compromised. If an attacker already has root access, you are totally hosed.
Yes, there's a security problem here, but it's not a technical one. In the tech support business we like to call this kind of trouble: Problem Exists Between keyboard And chair (PEBKAC). So yes, if you have a complete idiot as a system administrator, you've got real trouble, but you can't blame Linux for it.
Let's look at another example: Doki, a new backdoor trojan. This time around, although described by many as a Linux problem, it's not. It can only successfully attack Linux systems when whoever set up the Docker containers exposed the management interface's application programming interface (API) on the internet.
That's dumb, but dumber still is that for it to get you, your server's firewall must be set to open up port 2375. Here's a lesson from networking security 101: Block all ports except the ones you must have open. And, while you're at it, set your firewall to reject all incoming connections that are not in response to outbound requests. If your administrator hasn't already done this, they're incompetent.
Finally, let's consider the recent sudo command problem. This sudo security vulnerability was real, it's since been patched, but it requires, again, a case of PEBKAC to work. In this case, you had to misconfigure sudo's set up so that any user could theoretically run sudo. Once again, if you already have an insecure system, it can always get worse.
There's a common theme here. The problems often aren't with Linux. The problems are with totally incompetent administrators. And, when I say "totally incompetent," that's exactly what I mean. We're not talking subtle, small mistakes that anyone might make. We're talking fundamental blunders.
Whether you're running Windows Server, Linux, NetBSD, whatever on your mission-critical systems, if you utterly fail at security, it doesn't matter how "secure" your operating system is. It's like leaving your car keys in an unlocked car, your system will be hacked, your car will be stolen.
So, enough with blaming Linux. Let's blame the real problem: Simple system administrator incompetence.
> It's actually not that bad once you get used to it. It parallizes the startup process, and can be quite a bit quicker than initd. I've gotten to the point that I can create systemd unit files fairly easily, and can get custom processes to work on boot up pretty easily.
Honestly, I care far less about the "Look how fast it boots!" competition, than about "Look, it did everything in the right order, and it's the same order every time it boots".
The fact that I have to twist its arm -- hard, and with a lot of overhead -- to make it act even somewhat consistently is why I say it's a broken mess. Boot should be a deterministic process by default.
Of course, I say that as a system administrator of a considerable network, not a desktop user who wants his single computer to boot faster than the one his friend has.
THANK YOU! I was hoping someone post the reality of it! Priceless my friend!
It prints everything else fine. I’m using Adobe Acrobat for Linus.
Well said... :)
Thanks! That worked!
ShadowAce, you know I'm not talking about you there :-) I know you are a fellow Sysadmin, likely with a network to manage that dwarfs mine.
Have you tried the “document viewer” that comes boxed with Mint? Once I got the drivers from the printer manufacturer and put them in CUPS it works fine for me?
Someone suggested “okular” and it worked. Thanks.
Good deal... I have made a personal effort to try and learn and utilize everything that comes boxed with Mint before going and grabbing anything additional. :)
I haven’t even updated my kernel in three years now. Or grabbed any Mint updates, it’s been off. What for? New apps check for and go grab any missing dependencies during the install, so it brings it’s self up to date for that particular app.
Everything works fine so don’t try to fix it for no reason is my motto. And unlike windows, you can get away with this if you like with Linux.
And Linux is so easy to update. I have never been asked to reboot my computer (which can take half an hour or more on Windoze.)
Excellent. If you were viewing the PDFs through your browser or something, it might be that the application is not set up to print to your default printer.
Do you know of a good primer on systemd? It's a confusing mess to me. I much prefer the clarity of init scripts.
As for the boot speed, I'm not really concerned about that. It could take half an hour to boot, and I wouldn't care since that only happens 3 times in an average year (if that). I only reboot on kernel upgrades, and do those fairly infrequently. I reboot on kernel upgrades just to make sure nothing got badly bolluxed up. I'd rather know right away rather than have it bite me in the ass later on, and not know what change caused it.
Yep, see my comment #21 above.
Half an hour might bother me. But the difference between 1 minute and 3 minutes of Linux boot time is irrelevant. The hardware servers I maintain spend 3 minutes in hardware initialization and self-test before the kernel menu comes up. What's another few minutes?
The VMs of course are essentially nothing for BIOS time, and it's all Linux boot time. Scary quick. I just wish it was deterministic and consistent. Parallelizing is an invitation to problems, in my experience, and has to be done exceedingly carefully. The history and development of systemd has been been anything but exceedingly careful, IMO.
Something I recommend is to have /home on its own disk(s). When I did my last physical system rebuild, I replaced what was the old boot drive with a new reasonably sized SSD. After doing the OS install, none of my /home data had been touched. I just booted up and went back to work.
For backups, 'backintime' pretty much can't be beat IMO. It is similar to the Mac 'time machine' program and is based on rsync. It is freaking awesome. I have an external drive that I periodically swap out with another one that has backups going back to 2016. I have older backups on other external drives that I can recover stuff from as well if I need to.
Agreed on all points. The whole concept of a lack of a fully deterministic boot process scares the dickens out of me. Back when I was sysadmin with a crapload of boxes to support, it would have frightened me even more.
Now and then you run across an app that might require a reboot, but other than that it just pretty much handles everything on the fly as go along.
Never get any of those “you need to update to run this software” or “your OS version is out of date and will not run this”. They just don’t happen, everything old will run new, and everything new will run old.
Loving every bit of that peace of mind, lack of stress, and no BS proprietary hoops to jump through. :)
Mint cinnamon’s boxed version is called “timeshift”. And it is indeed awesome.
That was one of the advantages of Microstation (a CAD program) over Autocad. No older versions of Autocad would open up an newer version. So when any client upgraded their software, you had to, also or you couldn’t view their files.
I’ve got a laptop so a second, persistent drive is not so easy.
I do backups on an external. I use Deja Dup which works pretty good. Looks like Grsync is the graphical version of rsync, https://en.wikipedia.org/wiki/Grsync
I’ll have to check it out
Actually, I think ‘timeshift’ is different. It is more for configuration changes, rather than user data. Might be wrong about that.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.