by WallyFunk on 11/26/23, 3:13 PM with 118 comments
by devit on 11/26/23, 4:16 PM
You need to use VM-based isolation to have good security with Linux beyond that (i.e. use Qubes or a similar alternative).
by indymike on 11/26/23, 5:10 PM
"such as Windows, which is leaning heavily towards Rust, a memory safe language,"
by xorcist on 11/26/23, 4:55 PM
In what way? Compared to what?
Linux is not as secure as some research-level operating systems, but that comparison is not very useful for most people. Among mainstream operating systems, Linux contains comparably few surprises.
There's also the fact that, like with much of open source, when the developer's interest align with yours the tools get more effective. Contrary to what you read on the Internet, most actors in the Linux ecosystem take security seriously.
That the article references Spengler and Micay says a lot. That's like referencing the UNIX Hater's Handbook. That handbook was mostly right, but also not very practical. But over time it has done more for unix than most other texts, because it was mostly read by unix developers. The situation with these guys is mostly the same. A lot of the ideas voiced by them has been the basis for new features, just not in the form they were made originally.
by ramshanker on 11/26/23, 4:11 PM
by upofadown on 11/26/23, 4:53 PM
So if you want to show that Linux is insecure you have to directly show that it is.
by TrueDuality on 11/26/23, 4:05 PM
The problems pointed out in this post are almost all around usability as Linux on Desktop. The author admits the tools exist but are hard to use in most of the cases. Where features are missing its a misunderstanding of the Linux world.
A lot of these protections either live under different names outside of the Windows world and the ones that aren't don't exist because Linux protects things in a different less vendor-lock-in way. This is very apparent in the virtual machine section which are about protecting host kernel primitives from the VM... Linux doesn't expose _any_ host kernel primitives to the VM. The closest is narrow drivers, properly sandboxed and isolated in userspace, that are minimal and have their own security guarantees.
eBPF is far from a dangerous feature, C is only a dangerous language when that danger isn't managed, and the Linux kernel is top-of-class for managing those features, there is the same root boundary issue in Windows and is a deep source of security problems (root on Linux CAN be restricted through both seccomp and SELinux policies unlike SYSTEM).
Things could be better for sure in the Linux world, but pretty much everything besides secure defaults here requires a level of effort or access to attack that requires full compromise of the machine already. There is much lower hanging fruit that we need to clean up and the funny thing about Linux is that it trends hard toward security and quality over time.
You just have to look at time to fix patches for security vulnerabilities, not just in the kernel but in any packages maintained by security distributions. The author calls out not getting patches back-ported, without looking into the patches that don't get back-ported. RHEL won't backport fixes for features that aren't compiled in for example.
There was a post earlier this week about the CVSS scores being different between NVD and RHEL's bug trackers... It was because the networking functionality of that package wasn't compiled in so there was no possibility of remote execution .
by timetraveller26 on 11/26/23, 4:40 PM
by paravirtualized on 11/26/23, 5:56 PM
Each piece of software can be separated into its own VM. It uses read only templates for the root filesystem, making it difficult for malware to persist.
Templates have no access to networking or hardware making it difficult for them to be compromised, AppVMs where you run software can be treated as throwaway and be trivially destroyed after each use.
Dom0 has no access to networking, USB devices and runs no software. Total compromise would require a hypervisor escape.
It is designed with the assumption that you will be owned start to finish.
by mid-kid on 11/26/23, 5:39 PM
by cal85 on 11/26/23, 4:46 PM
Pedantry ;)
by hackeraccount on 11/27/23, 3:52 PM
1 - against a resourceful enough opponent a networked OS being used by a human is (probably) never secure.
2 - the biggest insecurity in any OS is the person running it
3 - a knowledgeable person can use / secure any OS to a degree that will avoid 99.99% of the vulnerabilities (excepting point 1)
I like Linux, I tend to think that when I want to increase security on a Linux system the tools are there and work. That said I'm sure that same thing can be said for OSX and Windows.
I do tend suspect that the best of the bunch - out of the box, naive user - is probably IOS. Linux is probably a close second because that naive user will find it harder to create problems and it's just a smaller target because of smaller installed base (and there's a little more heterogeneity among the distributions)
by Timber-6539 on 11/26/23, 4:26 PM
As far as I am concerned, no general purpose OS will ever come hardened to max defaults; which seems to be the standard applied for security here.
by SamuelAdams on 11/26/23, 5:15 PM
For example, I just installed Fedora Ashai Linux last night and discovered that the sshd daemon is listening on port 22 by default. Not sure if there was an easy to guess password for that, but it was not mentioned at all in the installer and could have been a big problem if I had not caught it.
by butz on 11/26/23, 5:42 PM
by 1vuio0pswjnm7 on 11/26/23, 9:02 PM
by tpoacher on 11/27/23, 12:00 PM
by rascul on 11/26/23, 6:32 PM
by PrimeMcFly on 11/26/23, 5:45 PM
Then again there is stuff like SELinux available which balances things out.
by MongoTheMad on 11/26/23, 6:15 PM
by Thaxll on 11/26/23, 4:58 PM
?
by betaby on 11/26/23, 4:50 PM
by asylteltine on 11/26/23, 5:10 PM
by wly_cdgr on 11/26/23, 4:38 PM
by rolph on 11/26/23, 3:54 PM
by theevilsharpie on 11/26/23, 4:13 PM
by kakaz on 11/26/23, 4:42 PM
by 1970-01-01 on 11/26/23, 3:47 PM