Linux being secure is a common misconception(madaidans-insecurities.github.io)
madaidans-insecurities.github.io
Linux being secure is a common misconception
https://madaidans-insecurities.github.io/linux.html
119 comments
Yeah, I don't see how windows or mac could ever be considered secure when you can't turn off telemetry and when the systems are closed source and cannot be publicly audited. Linux lets you be as secure as you need to be. The military for example in extreme cases will compile their own hardened version of linux and run it on a custom hardened FPGA soft core. Having that option makes it an actual engineering tool for security vs. a toy imo.
> I don't see how windows or mac could ever be considered secure when you can't turn off telemetry and when the systems are closed source and cannot be publicly audited.
Security != Privacy
Imagine home security monitoring your home 24/7. You lose privacy but gain security.
Security != Privacy
Imagine home security monitoring your home 24/7. You lose privacy but gain security.
Sure, but that's besides the point. What if my risk model means not sending packets under specific controlled circumstances because that would reveal my approximate location? What if the right apple or microsoft engineers were coerced into accessing my data? What if the government I am under becomes malicious and forces apple and microsoft to hack my device? Security can give privacy, but a loss of privacy is always a loss of security.
And imagine me monitoring your home. You lose privacy, and I know when you're on holiday and I can rob the place.
It matters who's doing the monitoring. With a home security system, it's you – or whoever you've delegated to –, and you chose to set it up; with these operating systems, it's somebody else, and you have little choice in the matter.
It matters who's doing the monitoring. With a home security system, it's you – or whoever you've delegated to –, and you chose to set it up; with these operating systems, it's somebody else, and you have little choice in the matter.
So far Microsoft and Apple haven't robbed anyone, unless you count Apple's RAM and SSD pricing as robbery, which is why many people and companies trust them despite the privacy concerns.
Companies and people who also strongly value their privacy, built and host their own on-prem infrastructure.
Companies and people who also strongly value their privacy, built and host their own on-prem infrastructure.
> So far Microsoft and Apple haven't robbed anyone
That's not the point. The question is, why should they be able to? And it's not about robbing but having total control over your own hardware.
Because when the moment comes, you can be sure they will do it. Adobe proved it when they disabled the software their customers in Venezuela used, just like that - because they could.
That's not the point. The question is, why should they be able to? And it's not about robbing but having total control over your own hardware.
Because when the moment comes, you can be sure they will do it. Adobe proved it when they disabled the software their customers in Venezuela used, just like that - because they could.
> The question is, why should they be able to? And it's not about robbing but having total control over your own hardware.
Technically nothing is stopping them from robbing you similar how noting is technically stopping your landlord from robbing you and yet most won't do it because they don't like the idea of going to jail.
We enter into an agreement that they won't rob you, and we trust that to the protection you have from the code of law, courts and the state enforcement where you live to protect you from the other party robbing you.
Currently in the EU, I see our governments have enough fangs to ensure tech companies won't rob us but those who seek the utmost independence should roll out their own on-prem.
>Because when the moment comes, you can be sure they will do it.
Then they'll get a class action lawsuit.
>Adobe proved it when they disabled the software their customers in Venezuela used, just like that - because they could.
Yeah, if you live in a country where the state is weak, companies can easily rob you, but if you live in a place without a functioning government like Venezuela, then Adobe is probably at the bottom of the list of entities who are out to rob you, way behind the government itself and various gangs.
Technically nothing is stopping them from robbing you similar how noting is technically stopping your landlord from robbing you and yet most won't do it because they don't like the idea of going to jail.
We enter into an agreement that they won't rob you, and we trust that to the protection you have from the code of law, courts and the state enforcement where you live to protect you from the other party robbing you.
Currently in the EU, I see our governments have enough fangs to ensure tech companies won't rob us but those who seek the utmost independence should roll out their own on-prem.
>Because when the moment comes, you can be sure they will do it.
Then they'll get a class action lawsuit.
>Adobe proved it when they disabled the software their customers in Venezuela used, just like that - because they could.
Yeah, if you live in a country where the state is weak, companies can easily rob you, but if you live in a place without a functioning government like Venezuela, then Adobe is probably at the bottom of the list of entities who are out to rob you, way behind the government itself and various gangs.
> Yeah, if you live in a country where the state is weak, companies can easily rob you, but if you live in a place without a functioning government like Venezuela, then Adobe is probably at the bottom of the list of entities who are out to rob you, way behind the government itself and various gangs.
This is hardly a counter-argument, on the contrary. Imagine being a Venezuelan and already suffering from high inflation rates, social unrest and so on. Now on top of that, you lose access to software you depend on.
Again, the point is not "being robbed". The point is that corporations are in control of important pants of your lives when they shouldn't.
This is hardly a counter-argument, on the contrary. Imagine being a Venezuelan and already suffering from high inflation rates, social unrest and so on. Now on top of that, you lose access to software you depend on.
Again, the point is not "being robbed". The point is that corporations are in control of important pants of your lives when they shouldn't.
Amazon deleted books from people's kindles though.
And Elon can disable your Tesla if he doesn't like what you're tweeting about it/him.
I think the reason that Linuxes are considered secure is the behaviour that is encouraged amongst its users. With Windows, users are encouraged to install software from random internet sites and there's no central method of updating software (without installing some third party updater from a random internet site).
Also, there's some design decisions made in Windows that lead to poor security. e.g. treating a file's extension differently, assigning it special meaning and then hiding it by default from the user.
Also, there's some design decisions made in Windows that lead to poor security. e.g. treating a file's extension differently, assigning it special meaning and then hiding it by default from the user.
I dislike this trope of knocking Windows because of no central method of updating software. Windows software by the very nature has automatic updates, just like Mac, for each application that is installed and well supported (usually). Most applications will check for updates on launch and/or periodically. You could use a third party utility but that just increases the chance of break-age depending on what gets updated. And on a Corporate/Enterprise Environment, all of these points are moot with centralized repositories. The core point is moot in so many ways and shows a lack of understanding of the ecosystem.
The file extension bit is sort of silly as well, as, it's what made Windows as user-friendly and wide spread as it is today. Better that than treating everything as a file and allowing anything to be piped anywhere.
I think the bigger point is the ethos behind the Operating System(s) and the opaque nature of Windows that causes these downstream effects.
The file extension bit is sort of silly as well, as, it's what made Windows as user-friendly and wide spread as it is today. Better that than treating everything as a file and allowing anything to be piped anywhere.
I think the bigger point is the ethos behind the Operating System(s) and the opaque nature of Windows that causes these downstream effects.
> The file extension bit is sort of silly as well, as, it's what made Windows as user-friendly and wide spread as it is today.
Are you sure? To me it looks like Windows got popular in spite of glaring security decisions, not because of them.
Are you sure? To me it looks like Windows got popular in spite of glaring security decisions, not because of them.
> The file extension bit is sort of silly as well, as, it's what made Windows as user-friendly and wide spread as it is today
I don't think that showing a file extension is massively confusing to people if they were always shown them. The problem is that there were real problems with a file extension looking like e.g. a picture, but instead had an executable extension e.g. image.jpg.exe
I don't think that showing a file extension is massively confusing to people if they were always shown them. The problem is that there were real problems with a file extension looking like e.g. a picture, but instead had an executable extension e.g. image.jpg.exe
Windows has had `winget` as a central package manager for a while now. It works great!
Thanks - this is the first that I'm hearing about it, though I don't use Windows that often.
Do many third parties use it?
Do many third parties use it?
I wouldn't be that enthusiastic about it. Best I can say is that it is not terrible. In simplified terms, all it does is download exe files from URL addresses that it gets from yaml metadata files, and then silently executes them; which in turn means that it leaves all of the installer's checkboxes unmodified, cluttering your desktop with icons in the process. On top of that, Windows Terminal has been failing to update on my machine as of late. I don't think this should be the standard for a first-party package manager, but I'd say it's par for the course for Microsoft.
It's also worth noting that all of Winget's code was initially taken from AppGet, without much recognition.[1] Apparently Microsoft cared just enough about that detail to mention the project they forked in passing, as part of a list of third-party package manager projects for Windows.[2] This is why, IMO, you should always first consider a copyleft license for an open source project.
[1] https://www.theverge.com/2020/5/28/21272964/microsoft-winget...
[2] https://devblogs.microsoft.com/commandline/windows-package-m...
EDIT: fixed vertical spacing.
It's also worth noting that all of Winget's code was initially taken from AppGet, without much recognition.[1] Apparently Microsoft cared just enough about that detail to mention the project they forked in passing, as part of a list of third-party package manager projects for Windows.[2] This is why, IMO, you should always first consider a copyleft license for an open source project.
[1] https://www.theverge.com/2020/5/28/21272964/microsoft-winget...
[2] https://devblogs.microsoft.com/commandline/windows-package-m...
EDIT: fixed vertical spacing.
Reminds me of the driver update utilities for Windows which notionally did update all your drivers, but also updates all of your viruses.
As opposed to running bash scripts from the Internet.
Well that behaviour is generally discouraged and whenever I do so, I give some due consideration to how much I trust the website. I can also eyeball what the script is doing which is more practical than disassembling some binary although it's common for the script to download a binary. Also, a lot of "install" scripts will set your system up with the software repository, so you use the standard system updates to also keep that software updated.
Great! I don't install driver autoupdaters from random sites either, so either subject is not an issue or your counterargument is invalid.
It's extremely common for Windows users to download and install malware, but very rare for Linux users to do the same, so I don't really understand your point.
You can read those scripts, you know. If you have a passing understanding of bash, it's pretty easy to understand what a script is doing and ensure it's not malicious.
Can you do that with a compiled executable?
Can you do that with a compiled executable?
You are comparing behavior of people who can read scripts with the behavior of people who consider random 3rd party driver updaters a good idea.
What user can do doesn't matter. It matters what they actually do.
What user can do doesn't matter. It matters what they actually do.
No, you are making that assertion. I brought up the driver thing as a joke, but you're the one that turned it into this inane whataboutism
Almost all windows applications are distributed as compiled binaries. Even very advanced users would find it difficult to audit most apps.
Bash scripts are in plain text, and idiomatic enough that it can be read by anyone with a passing familiarity with bash. Which is the very large majority of Linux users. The script very clearly states what it does, and if it doesn't, you shouldn't run it.
Driver updaters are nearly universally malware, and the common advice has always been to avoid them as such. Similarly, running random bash scripts from the internet without even looking is discouraged in the same way. Mystery binaries are much more dangerous than a script because you can't audit them, but the same advice is given for both: don't.
If what the user can do matters less than what they actually do, then Windows is the most insecure operating system by a very large margin. Windows users install malware at rates order of magnitude higher than any other system. Linux may as well have zero vulnerabilities compared to the shit that Windows users will blindly install.
You're right, it's stupid to compare these situations. So why are you doing it?
Almost all windows applications are distributed as compiled binaries. Even very advanced users would find it difficult to audit most apps.
Bash scripts are in plain text, and idiomatic enough that it can be read by anyone with a passing familiarity with bash. Which is the very large majority of Linux users. The script very clearly states what it does, and if it doesn't, you shouldn't run it.
Driver updaters are nearly universally malware, and the common advice has always been to avoid them as such. Similarly, running random bash scripts from the internet without even looking is discouraged in the same way. Mystery binaries are much more dangerous than a script because you can't audit them, but the same advice is given for both: don't.
If what the user can do matters less than what they actually do, then Windows is the most insecure operating system by a very large margin. Windows users install malware at rates order of magnitude higher than any other system. Linux may as well have zero vulnerabilities compared to the shit that Windows users will blindly install.
You're right, it's stupid to compare these situations. So why are you doing it?
> If what the user can do matters less than what they actually do, then Windows is the most insecure operating system by a very large margin.
What does Windows have to do with users ignoring best practice again?
> You're right, it's stupid to compare these situations. So why are you doing it?
I was not, you are excusing yourself from your own mistake. I was comparing people who install driver updaters with people who run random bash scripts from the Internet. Then you tried to convince me the right thing would be comparing with (imho mythical) people who read every bash script they download.
What does Windows have to do with users ignoring best practice again?
> You're right, it's stupid to compare these situations. So why are you doing it?
I was not, you are excusing yourself from your own mistake. I was comparing people who install driver updaters with people who run random bash scripts from the Internet. Then you tried to convince me the right thing would be comparing with (imho mythical) people who read every bash script they download.
> It matters what they actually do
Yes, and Windows users often install stuff from 3rd party websites whilst it's comparatively rare for Linux users.
Yes, and Windows users often install stuff from 3rd party websites whilst it's comparatively rare for Linux users.
> comparatively rare
This would need some substantiation. I personally had not seen many setups that did not require 3rd party websites.
This would need some substantiation. I personally had not seen many setups that did not require 3rd party websites.
Sorry, I have no numbers for that. However, typical Linux distributions include an incredible amount of software in their repositories, so it's usually only proprietary software that requires installation outside of the OS tools.
Linux vendors and lots of FOSS apps do collect telemetry, for eg:
https://popcon.debian.org/ https://wiki.debian.org/PrivacyIssues
Advertising is indeed much less common but is being explored. There have been some HN posts about the backlash that occurs when it gets introduced.
https://popcon.debian.org/ https://wiki.debian.org/PrivacyIssues
Advertising is indeed much less common but is being explored. There have been some HN posts about the backlash that occurs when it gets introduced.
Debian popularity-contest is as far as I know opt-in and very innocent compared to most of the telemetry stuff out there. Telemetry by default is evil, but trying to paint Debian as evil is a stretch.
I'm a Debian user and contributor for many years and wrote large parts of the privacy issues page above, based on facts I discovered while using Debian.
Certainly Debian isn't evil, and popcon is indeed opt-in. Popcon does make it possible for all Debian members (who can access the submission data) to probably identify other contributors and possibly others too. Also we do inherit lots of privacy issues from upstream projects. For eg GNOME calculator app in Debian still connects to the IMF and other websites even when.
Certainly Debian isn't evil, and popcon is indeed opt-in. Popcon does make it possible for all Debian members (who can access the submission data) to probably identify other contributors and possibly others too. Also we do inherit lots of privacy issues from upstream projects. For eg GNOME calculator app in Debian still connects to the IMF and other websites even when.
>Well, the biggest advantages of Linux are that the OS vendor is not itself malicious (in particular, does not collect telemetry, push advertisements or attempt to restrict your use of the system like Microsoft and Apple do)
Except they do: https://www.omgubuntu.co.uk/2022/10/ubuntu-pro-terminal-ad
https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-am...
Except they do: https://www.omgubuntu.co.uk/2022/10/ubuntu-pro-terminal-ad
https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-am...
That's seriously ridiculous. "Ubuntu let users know about automatic updates in the terminal".
It's incomparable to what MSFT does.
It's incomparable to what MSFT does.
Let them know about automatic updates? So you didn’t read either link.
One was advertising Amazon, the other was advertising their paid support service. NEITHER was telling users about automatic updates.
One was advertising Amazon, the other was advertising their paid support service. NEITHER was telling users about automatic updates.
Yes, a tiny, inobtrusive "hey, we offer paid support/automatic updates" after doing a terminal update.
That is easily solved by using Debian instead of Ubuntu.
So then what you meant to say was that _some_ Linux distros are not malicious.
The distributions maybe, but the producers of the Linux kernel are not.
I doubt the kernel maintainers of Windows or MacOS are involved in the advertisements inserted into the GUI of either OS.
The vast, overwhelming majority of them, yes.
Thinking about this. Would firing up various VMs via Boxes be similar to Qubes?
This line, to me, caused me to become much more critical of the article:
"such as Windows, which is leaning heavily towards Rust, a memory safe language,"
"such as Windows, which is leaning heavily towards Rust, a memory safe language,"
Microsoft has recently announced 10 million dollar investment into engineering efforts to use Rust as default systems language on Azure, alongside 1 million for the Rust foundation.
Azure runs on Windows.
Azure runs on Windows.
But Microsoft is currently rewriting major part of windows in rust.
https://www.theregister.com/2023/04/27/microsoft_windows_rus...
https://www.theregister.com/2023/04/27/microsoft_windows_rus...
That anything is not completely secure is a truism.
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.
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.
Compared to a standard economically motivated criminal hacking business that will certainly attack any commercial deployment (i.e. the default threat model). Security exists relative to your attackers, not compared to other security solutions. A cardboard box is a thousand times more resistant to penetration than a paper box, but neither is adequate to protect jewelry.
For software security, a trivial amount of resources like a mere 3 FTEs and 1 elapsed year will almost certainly defeat any Linux deployment. It will also almost certainly defeat any Windows, Mac, BSD, VMWare, iOS, Android, or any other commercial OS deployment. But, just because everyone only knows how to make cardboard boxes does not make any of them secure. And again, even if everybody else only knows how to make paper boxes, it does not make the cardboard box adequate. This is the case even if nobody in the entire world can do it; a cardboard box does not meet the minimum specifications, period.
For software security, a trivial amount of resources like a mere 3 FTEs and 1 elapsed year will almost certainly defeat any Linux deployment. It will also almost certainly defeat any Windows, Mac, BSD, VMWare, iOS, Android, or any other commercial OS deployment. But, just because everyone only knows how to make cardboard boxes does not make any of them secure. And again, even if everybody else only knows how to make paper boxes, it does not make the cardboard box adequate. This is the case even if nobody in the entire world can do it; a cardboard box does not meet the minimum specifications, period.
You literally have a comparison in the article, which lists security features from both windows and Mac that improve safety in different ways, and that linux lacks equivalents of.
The article offers no such comparison. It says that MacOS has sandboxing these days. That's good, but it's not a comparison.
The MacOS sandbox is really complex. It's a rule based system specified in XML, and an unknown portion of that complexity is in a kernel module. That's both more attack surface and more room for mistakes than for example Firejail, which the article in turn rules out for being too complex. That's not a comparison.
Traditional Linux software runs with the right amount of privileges. But that's not a fair comparison. Linux is a server OS from the start, which Mac or Windows isn't. Chrome is one example that really takes advantage of all the sandboxing possibilities Linux has. The article notes this as an example of how ChromeOS (which is pretty standard, as Linux distributions go) has much better security (what does that even mean?).
It all boils down to that standard Linux distributions allows the user to download and run unchecked binaries. Well, yes. But that's not more security, that's more like a difference in expectations. A modern desktop should allow for all applications to only access shared data with well defined protocols, but neither Mac nor Windows does that. One that does is Android (which is very much non-standard, as Linux distributions go). Feel free to use that and get your work done. Again, it's a matter of expectations.
The MacOS sandbox is really complex. It's a rule based system specified in XML, and an unknown portion of that complexity is in a kernel module. That's both more attack surface and more room for mistakes than for example Firejail, which the article in turn rules out for being too complex. That's not a comparison.
Traditional Linux software runs with the right amount of privileges. But that's not a fair comparison. Linux is a server OS from the start, which Mac or Windows isn't. Chrome is one example that really takes advantage of all the sandboxing possibilities Linux has. The article notes this as an example of how ChromeOS (which is pretty standard, as Linux distributions go) has much better security (what does that even mean?).
It all boils down to that standard Linux distributions allows the user to download and run unchecked binaries. Well, yes. But that's not more security, that's more like a difference in expectations. A modern desktop should allow for all applications to only access shared data with well defined protocols, but neither Mac nor Windows does that. One that does is Android (which is very much non-standard, as Linux distributions go). Feel free to use that and get your work done. Again, it's a matter of expectations.
Compared to Mac OS, Linux is hardly secure, at least without significant knowledge and customization that almost every user has no understanding of.
“I am secure”, ohh well “Xyz is secure”, is a common misconception. Anyone remember the old saying “ given enough time and tools, all locks are broken”.
People used to claim MacOS was so secure you didn't need antivirus. Turns out it was not very popular.
It is true. I don’t know a single person who runs any kind of antivirus on a mac and I’ve never heard of anyone getting a virus. Does it happen? Sure, there are 8 billion people in the world. Let’s not pretend mac needs an antivirus running like windows does.
Mac viruses exist. We can laugh at the cryptocurrency people all we want, but downloading sketchy apps, on MacOS (as well as Windows) has gotten more than a few people's cryptocurrency wallets drained.
Any Mac on corporate environment where liability is a thing, is quite certainly running some kind of systems scanner.
That’s true. And this piece of sh* consumes at least 1 GB of RAM constantly.
specifically, Santa.
https://santa.dev/
https://santa.dev/
Well… I mean, if you consider iOS an operating system, “so secure it doesn’t antivirus” is true for 99.9% of people.
I have personally never used antivirus on Mac. I’ve scanned once or twice with Malwarebytes when something weird was occurring but there was never anything.
I have personally never used antivirus on Mac. I’ve scanned once or twice with Malwarebytes when something weird was occurring but there was never anything.
The macs I support in my private circle run very well without an antivirus. It is anecdata of course but about 15 years of it for several "lambda" users.
Sometimes things are secure for no particular reason. Something might not do the things you think are important for security but that does not mean that that thing is insecure. There are almost an infinite number of things you can do in the name of security. The failure to do those thing is not evidence of a problem.
So if you want to show that Linux is insecure you have to directly show that it is.
So if you want to show that Linux is insecure you have to directly show that it is.
I think the amount of pain inflicted on the internet by security holes in IoT devices (most of which run Linux) goes a long way to show that Linux is not secure enough.
iOS being secure is also a common misconception. A bit of an extreme example but that is a meaningful problem as opposed to Linux on the Desktop cases.
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 .
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 .
Linux may not be totally secure but it is securest of all the viable options.
Depends on your definition of "secure" of course.
Chromeos and Mac OS are way more secure. Inb4 “chromeos is Linux” yeah but no, that’s just pedantic.
Half the OP is complaints about Linux kernel security. How is ChromeOS, which uses the Linux kernel, immune from these complaints?
ChromeOS uses an older kernel than even Debian Stable and RHEL. The older the kernel, the less the security risks. ChromeOS disables io_uring, which most (all?) other distros leave enabled. io_uring present a large attack surface. ChromeOS uses selinux and other containment technologies to contain the processes most vulnerable to adversarial input (namely, the browser and the media codecs). Fedora and RHEL use selinux, too, but there it is specialized in containing any internet services, e.g., a web server, that might be running on the machine: the browser and the media-file viewers (e.g., the PDF reader) are not constrained by selinux at all on Fedora and RHEL. This works fine for servers (which is Red Hat's bread and butter) but is almost useless for clients (devices used by end users). In contrast, the way selinux is used on ChromeOS is effective at securing a computer being used as an internet client.
It goes on and on. You should read the OP; it is really quite informative.
One thing that bothered me about this story for a long time was the fact that Google is pretty good at security, but Google allows its employees to use Linux on end-user devices. Then I realized that Google cannot trust its employees: with 40,000 software developers, Google must operate so as to be secure even if a few of those developers secretly hate Google and want it to fail or have been paid off or blackmailed into harming Google. The measures Google takes to protect against such employees (i.e., making sure that all code is reviewed by another developer before deployment, and making it so that a reviewer cannot choose which coders he reviews and vice-versa) naturally also protect against Linux running on the devices in front of the employees. (Even then Google is unsatisfied with the security of any of the publicly-available distros with the result that Google maintains its own internal Linux distro.)
It goes on and on. You should read the OP; it is really quite informative.
One thing that bothered me about this story for a long time was the fact that Google is pretty good at security, but Google allows its employees to use Linux on end-user devices. Then I realized that Google cannot trust its employees: with 40,000 software developers, Google must operate so as to be secure even if a few of those developers secretly hate Google and want it to fail or have been paid off or blackmailed into harming Google. The measures Google takes to protect against such employees (i.e., making sure that all code is reviewed by another developer before deployment, and making it so that a reviewer cannot choose which coders he reviews and vice-versa) naturally also protect against Linux running on the devices in front of the employees. (Even then Google is unsatisfied with the security of any of the publicly-available distros with the result that Google maintains its own internal Linux distro.)
> It goes on and on. You should read the OP; it is really quite informative.
I'm going to let this pass since I don't want to start a flamewar here but I think it's very rude to imply I didn't read the OP, and I think less of you for it.
So to summarize, you believe ChromeOS is immune to the Kernel's security vulnerabilities outlined in the OP because:
- it uses sandboxing (unrelated to kernel security) - disabled io_uring - it uses SELinux (unrelated to kernel security) which other distros do as well but you believe ChromeOS does it more effectively for desktop applications
I remain unconvinced.
I'm going to let this pass since I don't want to start a flamewar here but I think it's very rude to imply I didn't read the OP, and I think less of you for it.
So to summarize, you believe ChromeOS is immune to the Kernel's security vulnerabilities outlined in the OP because:
- it uses sandboxing (unrelated to kernel security) - disabled io_uring - it uses SELinux (unrelated to kernel security) which other distros do as well but you believe ChromeOS does it more effectively for desktop applications
I remain unconvinced.
ChromeOS' root filesystem is read-only with tamper-proof authentication. And notably, there is no way to autostart anything.
So in the worst case where an attacker gains code execution in the kernel, you just reboot the device and are guaranteed to be safe again.
So in the worst case where an attacker gains code execution in the kernel, you just reboot the device and are guaranteed to be safe again.
No, Windows, MacOS, iOS, Android and ChromeOS are all much more secure.
Android and chromeos are Linux based, so it's very interesting that 2 of your 4 most secure operating systems are linux.
But this is a perfect example of how the premise itself is fundemntally clickbait. The problem of insecurity is unrelated to Linux, but the execution and privilege model of userspace.
But this is a perfect example of how the premise itself is fundemntally clickbait. The problem of insecurity is unrelated to Linux, but the execution and privilege model of userspace.
I meant that Linux-based systems other than Android, ChromeOS and Qubes are the least secure of the common OS options.
Except they're not. They're the most permissive by default, maybe. But they're not the least secure.
If you put an assa abloy on your door, and then elect not to lock it. That doesn't mean assa abloy is the least secure lock.
Windows has a reputation for being insecure because if you try to keep someone out, they can still get in. This article was written on the idea that Linux is insecure, because when you don't try to keep someone out, they can get in.
If you put an assa abloy on your door, and then elect not to lock it. That doesn't mean assa abloy is the least secure lock.
Windows has a reputation for being insecure because if you try to keep someone out, they can still get in. This article was written on the idea that Linux is insecure, because when you don't try to keep someone out, they can get in.
Not quite, you can secure and lock down Windows too, the problem is that it isn't secure by default. And 90% of Admins don't bother with securing it other than sprinkling anti-virus on top.
Android, ChromeOS and Qubes are secure by default. Though I wouldn't trust a novice user with QubesOS.
Android, ChromeOS and Qubes are secure by default. Though I wouldn't trust a novice user with QubesOS.
Android and ChromeOS use the Linux kernel, they aren't GNU/Linux, as the termux folks are certainly aware.
For that reason, TFA said Desktop Linux, in order to avoid "pedanticism [sic]".
except chromeos is also desktop linux... unless desktop has a different definition than the one I know?
Windows will: spy on you, serve you advertisements, reboot autonomously, destroying your open work, install software without consent, report your browsing behavior to advertisers, literally steal your email password, upload all your files to one drive without consent, forcibly change your default browser, insert aggressive ads for Edge in front of the Firefox download page, show you clickbait tabloid articles in the taskbar.
Honestly I'm not sure how you can consider any of that secure.
Honestly I'm not sure how you can consider any of that secure.
>spy on you, serve you advertisements
this, just like many other points is not security, sorry.
Security is about (among other) CVEs, not ads.
>reboot autonomously, destroying your open work,
bullshit
>upload all your files to one drive without consent
without consent? did onedrive magically figure out your MS credentials?
>steal your email password
what?
this, just like many other points is not security, sorry.
Security is about (among other) CVEs, not ads.
>reboot autonomously, destroying your open work,
bullshit
>upload all your files to one drive without consent
without consent? did onedrive magically figure out your MS credentials?
>steal your email password
what?
> Security is about CVEs, not ads
You have this very backwards, CVEs are about Security and not the other way around.
Consider why we care about security in the first place:
- We don't want our private data stolen
- We don't want a malicious program stealing our electricity and computing resources
- We don't want adware injecting advertising into our browser toolbar, homepage, email client, etc
- We want our family to be able to safely use our computers without having to worry about them falling for scams
- We want peace of mind
Unconsented advertising is absolutely a violation of security in the same way a salesmen breaking into your house to sell you things is. Don't miss the forest for the trees here.
Do not forget that the CVE system is fundamentally just a tool for tracking computer security vulnerabilities, a tool that unfortunately incentivises pedantic security researchers to fill it with garbage to pad their resumes, a tool who's authority is worshiped like a god by corporate IT departments despite it's inadequacies, but a tool nonetheless which just happens to be better than it's alternatives.
The fact that deliberate security violations enforced by the vendor are not tracked by the CVE system, is not evidence of Security, but simply a limitation of the system.
You have this very backwards, CVEs are about Security and not the other way around.
Consider why we care about security in the first place:
- We don't want our private data stolen
- We don't want a malicious program stealing our electricity and computing resources
- We don't want adware injecting advertising into our browser toolbar, homepage, email client, etc
- We want our family to be able to safely use our computers without having to worry about them falling for scams
- We want peace of mind
Unconsented advertising is absolutely a violation of security in the same way a salesmen breaking into your house to sell you things is. Don't miss the forest for the trees here.
Do not forget that the CVE system is fundamentally just a tool for tracking computer security vulnerabilities, a tool that unfortunately incentivises pedantic security researchers to fill it with garbage to pad their resumes, a tool who's authority is worshiped like a god by corporate IT departments despite it's inadequacies, but a tool nonetheless which just happens to be better than it's alternatives.
The fact that deliberate security violations enforced by the vendor are not tracked by the CVE system, is not evidence of Security, but simply a limitation of the system.
>Consider why we care about security in the first place:
>- We don't want our private data stolen
>- We don't want a malicious program stealing our electricity and computing resources
>- We don't want adware injecting advertising into our browser toolbar, homepage, email client, etc
>- We want our family to be able to safely use our computers without having to worry about them falling for scams
>- We want peace of mind
Almost all those points are basically the same thing repeated differently:
We don't want somebody else mess with our computer, but that "somebody else" almost always is 3rd party - so not you (user) and not Microsoft (vendor).
Ads from vendor aren't considered as a security issue (unless very edge cases).
They are annoying, but in the principle they aren't security defect (unless badly implemented)
>- We don't want our private data stolen
>- We don't want a malicious program stealing our electricity and computing resources
>- We don't want adware injecting advertising into our browser toolbar, homepage, email client, etc
>- We want our family to be able to safely use our computers without having to worry about them falling for scams
>- We want peace of mind
Almost all those points are basically the same thing repeated differently:
We don't want somebody else mess with our computer, but that "somebody else" almost always is 3rd party - so not you (user) and not Microsoft (vendor).
Ads from vendor aren't considered as a security issue (unless very edge cases).
They are annoying, but in the principle they aren't security defect (unless badly implemented)
Please define security in a way that excludes all possible classes of "third party doing things on your machine without your knowledge or consent"
> what?
Probably referring to this https://news.ycombinator.com/item?id=38212453
Probably referring to this https://news.ycombinator.com/item?id=38212453
Check the recent headlines. Windows is pushing user files to one drive and stealing email passwords to proxy your email account on Microsoft servers.
>>reboot autonomously, destroying your open work,
>bullshit
Honestly baffled how you can deny this. Windows rebooting on its own is one of the most defining features.
>this, just like many other points is not security, sorry.
Bullshit.
>>reboot autonomously, destroying your open work,
>bullshit
Honestly baffled how you can deny this. Windows rebooting on its own is one of the most defining features.
>this, just like many other points is not security, sorry.
Bullshit.
>Honestly baffled how you can deny this. Windows rebooting on its own is one of the most defining features.
There's only scenario where I can imagine Windows rebooting ""on its own""
You've scheduled an update or you're delaying update for long peroid of time?
>>this, just like many other points is not security, sorry. >Bullshit.
How so? in the principle ads aren't security issues (unless badly implemented)
>Check the recent headlines. Windows is pushing user files to one drive and stealing email passwords to proxy your email account on Microsoft servers.
I've literally googled: "windows stealing email passwords"
and the very first thing is article from 2016 and the other are about Malware/Scam, so how what article are you talking about?
There's only scenario where I can imagine Windows rebooting ""on its own""
You've scheduled an update or you're delaying update for long peroid of time?
>>this, just like many other points is not security, sorry. >Bullshit.
How so? in the principle ads aren't security issues (unless badly implemented)
>Check the recent headlines. Windows is pushing user files to one drive and stealing email passwords to proxy your email account on Microsoft servers.
I've literally googled: "windows stealing email passwords"
and the very first thing is article from 2016 and the other are about Malware/Scam, so how what article are you talking about?
It's highly unlikely that any operating system can be as secure as Qubes OS[1], simply by considering the model itself. Especially if using Whonix[2] VMs to browse the internet. It is based on GNU/Linux and Xen.
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.
[1]: https://www.qubes-os.org/
[2]: https://www.whonix.org/wiki/Qubes
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.
[1]: https://www.qubes-os.org/
[2]: https://www.whonix.org/wiki/Qubes
There's no worse way to be right than being technically right. Most of these points are essentially the state of the art of desktop operating systems, or pure speculation, and the fact that they aren't perfect or widely used yet is usually because of tradeoffs that must be made in favor of usability.
> Due to inevitable pedanticism
Pedantry ;)
Pedantry ;)
I think the two important statements which I think almost everyone would agree with are:
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)
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)
Flatpaks don't necessarily aim to sandbox applications by default. They just give you the platform to DIY in the easiest way possible, esp when coupled with Flatseal. If we really want to criticize Flatpaks for allowing access to /home or x11 for compatibility reasons, then we should do the same to traditional applications which are packaged non-sandboxed with the same permissions anyways. And before you say that this is an issue because of unknown contributors to popular Flatpak applications, verified apps from the project owners themselves ship with these same "express" permissions.
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.
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.
People also assume all defaults are “safe”, and that the out of the box configuration does not need to be reviewed.
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.
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.
> discovered that the sshd daemon is listening on port 22 by default
Your comment confused me and I had to read it more than once. I’d expect the SSH service to default to listening on the default port and I’d be annoyed if a distribution had configured the sshd daemon to default to listening to a port other than 22.
I’m guessing that your main problem with the distribution is that the SSH service was automatically enabled in the first place (without your knowledge).
Your comment confused me and I had to read it more than once. I’d expect the SSH service to default to listening on the default port and I’d be annoyed if a distribution had configured the sshd daemon to default to listening to a port other than 22.
I’m guessing that your main problem with the distribution is that the SSH service was automatically enabled in the first place (without your knowledge).
Yes, sorry you are right. My main gripe is that the sshd service was enabled and running by default.
I agree that "Linux" is not secure, but there must be at least a few Linux distributions that are made as secure as they can be.
The article mentions reducing attack surface several times (in the context of VMs, sandboxing, etc.) but it never considers the ability to reduce the surface of the entire OS (no VMs, sandboxes, etc.). What are other OS that make shrinking the size of the entire OS even easier. Do they exist.
Placing Flatpak as the top argument on that list to demonstrate insecurity for linux more generally, is a bit like saying your house is insecure if you use a padlock instead of a proper lock, so you shouldn't own a house more generally.
Might be that none of that really matters. Figure out what security goals you want to meet for your use case and take the necessary steps to get there.
With the kernels devs attitudes toward security vulns, of course it is.
Then again there is stuff like SELinux available which balances things out.
Then again there is stuff like SELinux available which balances things out.
Am I missing something? Isn't SELinux supposed to mitigate/stop the attacks described?
"Most programs on Linux are written in memory unsafe languages, such as C or C++"
?
?
It would be a reasonable point, if it were backed up by hard numbers.
Linux and Windows both offer C++ as a first-class option for graphical desktop applications. They also both offer first-class safe alternatives. Windows has .Net. Linux has, say, Python bindings for Qt and for GTK.
It could be that Linux desktop applications are more often written in unsafe languages, but it's not self-evident.
Linux and Windows both offer C++ as a first-class option for graphical desktop applications. They also both offer first-class safe alternatives. Windows has .Net. Linux has, say, Python bindings for Qt and for GTK.
It could be that Linux desktop applications are more often written in unsafe languages, but it's not self-evident.
"Most programs are written in memory unsafe languages, such as C or C++"
Does that fix it for them?
Does that fix it for them?
I mean both are true kind of, but a ton of Mac and iOS stuff is written with swift…
Does the author really not understand what memory unsafe means?
What do you mean? it is right
Meh! From the article "In macOS, all applications require user consent before accessing sensitive data"." Well and once given have access to all "Files and folders Note: Includes: Desktop, Documents, Downloads, network volumes, and removable volumes", absolutely in a same way as in Linux.
Additionally when installing packets in Linux I would say you give permissions by answering 'yes' to apt/dnf. Such small nuances between MacOS and Linux are not important. Additionally author ignores the fact SELinux may provide protection from accessing random files by random app.
Mac OS and iOS are beyond a doubt the most secure operating systems. I’m not saying they are bulletproof, but are definitely the most secure compared to anything on the market. Linux desktop is laughably insecure, as much as I love it. Windows? I guess with hardware backed bitlocker(apparently not even the default lmao) is alright.
It is easy for ugly people to be chaste, if you know what I mean
so should we all switch to whonix ?
(2022)
Is Microsoft founding FUD campaigns again?
Or the usual case of "My OS is tracking me and showing me ads, but you know, Linux is not perfect either."
Linux being insecure is also a misconception, because its so damn fragmented. Only when a Linux flavor matures does it become a target for hackers.
similar to the old memes of windows 8 being malware proof because it's incompatible with most of it?
You need to use VM-based isolation to have good security with Linux beyond that (i.e. use Qubes or a similar alternative).