Linux being secure is a common misconception
madaidans-insecurities.github.io
madaidans-insecurities.github.io
You need to use VM-based isolation to have good security with Linux beyond that (i.e. use Qubes or a similar alternative).
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...
It's incomparable to what MSFT does.
One was advertising Amazon, the other was advertising their paid support service. NEITHER was telling users about automatic updates.
Security != Privacy
Imagine home security monitoring your home 24/7. You lose privacy but gain security.
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.
Companies and people who also strongly value their privacy, built and host their own on-prem infrastructure.
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.
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.
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.
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.
Can you do that with a compiled executable?
What user can do doesn't matter. 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.
This would need some substantiation. I personally had not seen many setups that did not require 3rd party websites.
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?
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.
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.
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
Are you sure? To me it looks like Windows got popular in spite of glaring security decisions, not because of them.
Do many third parties use it?
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.
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.
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.
"such as Windows, which is leaning heavily towards Rust, a memory safe language,"
https://www.theregister.com/2023/04/27/microsoft_windows_rus...
Azure runs on Windows.
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.
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.
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.
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.
So if you want to show that Linux is insecure you have to directly show that it is.
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 .
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.
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.
Android, ChromeOS and Qubes are secure by default. Though I wouldn't trust a novice user with QubesOS.
Honestly I'm not sure how you can consider any of that secure.
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?
>>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.
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?
Probably referring to this https://news.ycombinator.com/item?id=38212453
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.
>- 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)
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.)
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.
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.
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.
Pedantry ;)
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)
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.
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.
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).
Then again there is stuff like SELinux available which balances things out.
?
Does that fix it for them?
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.