The Tinfoil Chat setup uses optocouplers to enforce one-way data transmission.[0] And one can use inexpensive CD-R and micro SD cards for single-use data transfer. But transferring anything but plain text is dangerous.
Thanks for mentioning the octocouplers implementation, it looks very interesting and I'll look it. Other options I'm aware of to avoid USB and complex drivers/protocols:
I wonder if one could cut up QR codes, and store pieces separately. If that were done in Gimp or whatever, there could be multiple copies of each piece.
I meant actually cutting them with a sharp knife, or scissors. So you could hide pieces in different places. For stuff like URLs, passphrases, wallet seeds, etc.
I wish the author had linked to some citations on a lot of the points brought up. It came off as flippant, particularly the dismissal of snap (of which I am not a fan but not aware of gaping security holes other than the forced updates). But possibly this piece wasn’t intended to blow up on HN.
Some of the stuff like code signing is philosophically incompatible with a modular OS where people are often compiling their own binaries, but many of the points raised are good.
> Windows and MacOS enforce signature checking on all binaries.
This is not a meaningful security feature. If the signature has to be from the manufacturer then you can't so much as write your own shell script, which is useless. That is a cage, not a security measure. But if the user can sign their own binaries then the signature is the equivalent of the execute bit -- you have to tell the system something is executable before it will execute it. Linux has had that forever.
The signature could be tied to a sandbox. Signed apps each have their own sandbox. User signed apps all get thrown into the same sandbox. Otherwise I agree. A signature can't actually meaningfully exist as a security feature in an open source operating system where you are able to compile every piece of software yourself.
Signatures are meaningful when the keys are more secure than the servers hosting the data.
If you download software from a hacked server that serves you malware, the signature check will fail. In contrast, the execute bit can be changed by anyone.
The problem is that you need to get the authentic public key of the software distributor to verify the signature. If an attacker is able to forge the public key, they can easily
forge the signature and the signature check will succeed.
> The problem is that you need to get the authentic public key of the software distributor to verify the signature.
Right. If you already have a secure channel to receive the signing key over, you can just use it to receive the software to begin with.
Meanwhile we do have a CA system that lets you download the software via TLS. It's not perfect, but breaking TLS or compromising a CA are not even close to common methods of delivering malware.
> Right. If you already have a secure channel to receive the signing key over, you can just use it to receive the software to begin with.
Note that the secure channel sometimes has more limited bandwidth. An example would be reading part of your public key over the phone, which is not practical for the actual software.
There are other considerations that make using the secure channel for the software itself impractical. For example, you can have many people publish known public keys on their website, so that
other people could verify them with some majority voting.
> Meanwhile we do have a CA system that lets you download the software via TLS. It's not perfect, but breaking TLS or compromising a CA are not even close to common methods of delivering malware.
The main risk is not breaking TLS or CAs, but rather compromising the server that you download the software from, and serving malware instead. Indeed, if the same server is used for serving the public key,
you don't gain much, because the attacker can just generate their own key pair, sign the malware, and publish their key. But ideally, the public key would not be published from the same server,
making an attack more difficult.
> Note that the secure channel sometimes has more limited bandwidth. An example would be reading part of your public key over the phone, which is not practical for the actual software.
In theory, sure. In practice ordinary users are not calling up the software developer and having them read their public key over the phone.
> There are other considerations that make using the secure channel for the software itself impractical. For example, you can have many people publish known public keys on their website, so that other people could verify them with some majority voting.
You could do the same thing with the application binary itself and have them compare hashes.
> But ideally, the public key would not be published from the same server, making an attack more difficult.
You could get the same benefit from publishing only the hash of the software on the separate server. The signature is redundant, and is even worse than the hash because it introduces private key compromise as an attack vector.
The main benefit of signatures is for an app distribution system that needs to distribute multiple apps or updates, so then it can deliver the public key once and reuse it. But now you're talking about the package manager and Linux package managers already do that.
> You could do the same thing with the application binary itself and have them compare hashes.
This is not scalable to software updates, which happen much more frequently than (long term) key updates.
With hashes you would need to publish a new hash for every update, but with public keys you're fine.
> You could get the same benefit from publishing only the hash of the software on the separate server. The signature is redundant, and is in fact worse than the hash because it introduces private key compromise as an attack vector.
Similarly to the issue I mentioned above, this introduces a hassle because the hash will change every time you update the software, which means you will need to update it. In addition, the system serving the hash/key should have some additional safeguards for updating it (because it's somewhat more sensitive), making the update probably more cumbersome.
Could you clarify what attack is possible with keys that is not possible with hashes?
Well. The principle of Linux was and still is to give tools and have users use them.
It gets out of the users way to use them.
One can always use firejail or other sandboxing solutions to do that.
Chrome itself is a security nightmare, always with the mic on and listening.
Microsoft and Apple also have CVEs unattended.
Binary checks before starting a program? Why I have a package-manager that does the checks.
Untrusted binaries are ususally installed with local user rights in a seperate path or best, not run at all(never needed to turn to some website offering tools since moving to linux aeons ago).
Not all distros use Flatpack or Snap, and I hope it remains that way regardless of how fiercely Canonical is pushing for it.
Granted, the out of the box security provided by Linux as a Desktop OS is behind the Windows/MacOS one;Only think of the non-existing firewall rules on a fresh Ubuntu installation.
But I think that is ok, because installing Linux is a conscious decision, unlike using a preinstalled Windows or MacOS.
So, if you do that move from one OS over to another, the user should read up and not expect the community to hold their hands without asking questions.
Not everything is perfect, yes moving the toolchain would be nice, but then again, most a community run projects, so the user needs to know about locking their basement as well. Hence the audience is/should be more technical minded anyways.
IMHO another post about comparing apples and oranges leaving out second-level effects.
Just an example:
Looking for CVE-entries https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=MacOS , https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Linux , https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Windows .
We see that MacOS has the fewest and Windows the most CVEs.
(So it doesn't matter that Microsoft closes the CVEs quickly and Debian might take some time (haven't really run metrics on that one), there is a huge attack-surface on Windows, compared to Linux and new once have to pop up all the time :D)
That isn't looking into severity, because a chaining of medium CVEs might also lead to a compromise as well ,and not everything requires system or root. User might be fine as well.
I see a reflection of favoured OS. Only few people use MacOS (some artists, companies streamlining their assets for maintenance and rent,etc.). Windows, on the other hand, was always the big dog on the desktop market. Naturally, maleware authors focus on the biggest market.
Lack of privacy is lack of security. This is true even if you're only interested in "hard" security concerns. For example, consider that keystrokes can be reconstructed from audio, which means that being able to record from your mic means being able to gather your passwords.
As the other guys said.
And it is not just that.
Chrome is, considering it's architecture and purpose, a minion in a botnet, working for google to harvest data.
They even got a lawsuit pending because they were even tracking users in privacy mode.
This stuff cannot happen with IE, or FF.
Brave, Vivaldi, I dunno, don't use them, but I am weary that they are using the same rendering-engine (and soon Redmond as well) (well depends where the G-men(what a pun) put their mischiveous code in).
Because it is a pipedream to expect a privacy-compatible product from a company that build it's empire on mining the users data to the bit.
And that's ok, there's nothing wrong with tools being specialised for certain small markets. It makes them significantly better for those people than being forced to use a ill fitting tool for someone else.
Consolidation and lack of competition makes for a worse experience.
While I think you are right to some extent, articles like the parent's are mostly aimed at people claiming 'Linux Desktop is actually better for grandma'. The reality is that grandma is going to be better protected while running Windows or MacOS or Chrome OS. If she's running Linux, she is wide open.
Also, some of the most common practices on Linux that are claimed to be superior from a security standpoint are just bad. For example, the package manager is very nice, but when you want to install anything that is not in the official repos, your options get just as bad as windows, or worse, despite what many people think. A common recommendation in advanced projects is to add their apt/yum repo to your system, which is not only equivalent to downloading stuff off the internet, it is also you registering them as trusted to deliver updates to your system forever. On Windows, you at least have some anti-virus tool scanning for known malware, so you still have a small chance that you won't be allowed to run some well known malware from years ago.
The external provided software repos are one thing I find superior on Linux, compared to macOS and Windows. It gives you an OS managed way to do updates to 3rd party providers, as opposed to each app shipping their own update code, many times running as a background daemon. On macOS, the situation for apps outside of the app store is a ghetto. Not sure about Windows as I don’t use it often, but I suspect it’s similar to macOS.
Sure, it has advantages, but it is less secure than downloading a binary, since you can check if the binary is downloading stuff off the internet or not, while the repo could be benign today, but malign tomorrow when the company hosting it gets bought, for example.
Also, from what I've seen, custom updaters are still the most common way of delivering updates for Linux outside the distribution-maintained official repo, as most people ship software for many distributions, and maintaining one repo per distribution quickly gets annoying. Ironically, this wouldn't be a problem on Windows or MacOS, if they decided to include a package manager with support for custom repos (the app stores allow side-loading, but do not allow custom upstream, as far as I know).
> The reality is that grandma is going to be better protected while running Windows or MacOS or Chrome OS. If she's running Linux, she is wide open.
Strongly disagree. The linux desktop has something like 1% of the marketshare and is far from the lowest hanging fruit. And basic, sane security defaults are plenty good for simple web browsing and emailing.
My grandma used to get calls 2-3 times a month from "Microsoft" and "Comcast" trying to get her to download team viewer and cough up some passwords to Windows 8. She eventually got phished by downloading something dumb via email. I put her on the Ubuntus, with some tweaks, and she's doing fine. 10/10 would do it again.
> For example, the package manager is very nice, but when you want to install anything that is not in the official repos, your options get just as bad as windows, or worse
Grandma ain't installing Steam or an obscure 3rd party metasploit framework -- standard Ubanto repos are fine. She doesn't need rpmfusion to access Office365 emails.
> On Windows, you at least have some anti-virus tool scanning for known malware
Clam-AV is a thing in Linux and works fine -- we used it on mail relays a while back and had decent results. If you're putting trust in the default MS virus protection you're naive.
I don't think anyone is seriously applying those to a desktop system.
They are both based on the Linux Security Module subsystem; which is just too low level to be effective at desktop security. Essentially, they suffer from the same problem as traditional UNIX permissions: no one cares that the attacker cannot access system files. The user's bank account is in their home directory.
And that defeats a large portion of how programs work by first having root to bind to low ports, etc then forking a worker not to mention you have to restructure your program for seccomp vs ifdef for pledge. There are a bunch of ways of sandboxing on Linux but not many projects use it because implementing it is just painful, compared to pledge even external projects outside of openbsd will accept simple ifdef patches to support easy sandboxing.
Fortunately socket activation is gaining support. The whole idea of having a privileged process just to bind can be skipped. But even without it, I'm not sure why it matters for seccomp - you bind then you apply the policy. Just like typically you first bind, then setuid.
"flatpak and snap are both security nightmares" and then link to flatpak article... Come on at least bother to explain... As far as I know - with all bad publicity snap has recently - it does isolate package and you don't give root to package maintainer.
I'm dubious of some of these -- the code signing thing strikes me as not that compelling for reasons other comments have already pointed out. Others are very valid.
But more than "how are we doing vs Apple and Microsoft?" I'd kinda prefer to set the bar a bit higher. Desktop operating systems (all of them, at least with actual users) are just completely architecturally backwards for the reality of our modern security landscape, and what users need from their system. Protection boundaries are still mostly between different users. for most systems that's borderline useless, as there's only one user. Meanwhile every app runs with the full authority of the user and can do anything they can do.
Smartphones are a little better; Android equates "user" with "app" which is at least vaguely useful. But the permissions you end up with are still too coarse grained.
There are better designs out there. For example: web pages can ask the user for a file without getting access to everything the user owns (or at least in the case of Android, all of their files). Why can't native apps do this?
They do in UWP, macOS, ChromeOS sandboxes, to different levels of detail, but so far most developers have resisted to them thus users can't get to use them.
I agree that Android app security model is much better than desktop Linux (of course, they had the privilege of designing a new system without backward compatibility concerns and after learning lessons from other systems).
The main issue with using that model for desktop Linux is that apps where not developed with this model in mine. So when an app wants to access your webcam, it tries to do it directly and doesn't ask the OS to grant
permission. Similarly when accessing any files.
I guess it's possible in theory to trace any system calls the app makes and accordingly trigger permission requests to the user. Since that didn't happen, maybe it just breaks to many apps to be effective.
BTW, installed apps could create their own UID to isolate themselves, but most developers/distros don't bother doing it. I should not that I did see a significant improvement in running systemd services as separate
users, but I rarely see it for user facing apps.
A better option than only using a separate UID is containerization, and things like docker, firejail, bubblewrap, etc, are useful here.
But Linux containers are not considered secure enough (at least compared to VMs). The real gold standard in terms of security is QubesOS, but you pay for that security in performance and ease of
use.
> Firejail is a SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.
I think the author is generally right (especially about sandboxing!), but picked a few funny examples:
* Windows page signing is a feature of Authenticode, and applies specifically to "high integrity" kernel drivers. It's basically a niche of normal code signing and should be treated as such.
* Windows just (as in, within the last 6 months) got hardware-backed control flow protection, via Intel CET. They had to add a new debug type (`IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS`) to the debug section to make space for it in the PE format. It'll probably take a few years to become popular, assuming that Microsoft hasn't badly broken it the way they did RFG.
* Modern iOS/Apple mobile hardware is generally a poor contrast: it's homogenous in terms of CPU features in ways that Linux can only dream of, and benefits from Apple's walled garden approach. Linux distros can barely get people to fetch automatic updates; getting them to buy CPUs with hardware CFI features (a la Apple's PAC) is a pipe dream.
On Android side of the mobile OS fence, Google is now enforcing ARM memory mitigations starting with Android 11 and it builds up on the OS lockdown features that they have been adding since Android 7.
it starts all with application devs and distribution package maintainers. users shouldn't even have to know about these things.
- things could be improved if (userland)application maintainers (NOT packaging maintainers) actually bothered to ship apparmor (and/or SElinux) profiles and also properly maintain them for all packages. This will only happen if distributions make them mandatory instead of relying on some 3rd party maintainers.
- it seems that QA in general (and test coverage especially) within Linux distributions isn't very strict (I'm only familiar with Debian/Ubuntu here).
- Haven't seen many services make use of the systemd.exec[1] restrictions in unit files. should be mandatory for all system services to implement these (has to be done by devs not distribution packaging maintainers).
- While it's nice that Debian claims that apparmor is enabled by default now it hides an ugly truth that becomes visible when running `ps auxZ | grep '^unconfined'` ... most applications don't even have a profile and even when you install apparmor-profiles-extra there are only a handful.[2]
- firejail is cool but most people never even heard of it (there is also an overlap in some functionality between apparmor/firejail - and even systemd.exec)
There is always going to be a trade-off between strictness/QA and integrating changes/new packages. but raising the bar can only be possible by having developers maintain these things better and holding them accountable during the distribution packaging. We can't expect the user to figure out what system-calls a process makes so that they can whitelist it themselves.
If Linux on the desktop is ever to compete from a security pov with Apple/Windows then this needs to be done under the hood. While many of my family (including my 70 yro auntie) uses Linux successfully they should never have to know what apparmor/SElinux/etc even is.
[2] The Debian wiki (https://wiki.debian.org/AppArmor/HowToUse#Enabling_profiles) states: "Beware though: many profiles are not up-to-date and will break functionality in enforce mode, be ready to debug!" <- this shifts the effort to the user (in other words security is available only if one is prepared to implement it by themselves).
More broadly, even in systems such as Windows, arbitrary programs have way too much access to the system, especially the filesystem. A lot of effort is put into patching exploits that allow for a program to gain root, yet this is largely irrelevant for desktop users [1]. If malware takes over system files, the operating system can just be reinstalled. The relevant threat is malware encrypting or stealing personal files (which every program can access), such as pictures, documents, browsing history, etc. Currently, all it takes is a single sketchy freeware utility without admin access to destroy/steal all of your personal data.
I would envision a whitelist system where programs by default can only access files in their own directories, but the file explorer would mediate access to files opened in the program. So if a file is double clicked in explorer, the corresponding program gains access to that file. Likewise, the "Open" feature in the program would have to call the explorer API for the file selection dialog, which would also give it permission. There are certainly lots of edge-cases that would have to be ironed-out.
Another nobrainer is to put permission for network access on a whitelist, in addition to other permissions. It could work similarly to the permissions found on mobile, but it should be possible to install the program anyway without granting it permissions, so that developers don't simply ask for everything as is standard on mobile. Of course, this system would introduce UX headaches for non-technical people which would need to be worked on, but it should at least be an option for security-conscious people.
I’m not sure you’re aware but you basically described the way it works in the latest macOS. If an app wants to touch something in user folders, it has to ask for permission.
Perhaps what is broken is not our operating systems, but the notion that a computer program running on one's own computer can be an untrusted agent of a third party. I don't the tools in my collection to be isolated from each other, dangerous creatures in a computerized zoo. I want them to be composable elements of a cohesive whole. I want them to share data so promiscuously that is difficult to tell where one program stops and another begins. Today, this vision of computing is best realized in the free software world, and I don't believe that is a coincidence. To make it work, your tools must be trustable, and the problem of trustable computing is fundamentally intertwined with the issue of free software. Can it be reconciled with a commercial model of software? I don't know, but if it's a choice, then I've made mine.
While I can appreciate your vision, that seems too detached from the current reality.
Software development is a highly distributed system with many human participants with different (and sometimes conflicting) goals and skills. And to make it effective, you almost always need to reuse software
created by many other people that you don't know (which incidentally creates a huge opportunity for supply chain attacks).
In this reality, you get very little assurance about the authenticity and security of anything you use.
Wayland remains very immature, and it still has significant shortcomings in hardware support. It's a beta-level technology at best, while Xorg has 20 years of stability behind it. It isn't responsible to suggest it as an alternative.
Many people (me included) use Wayland as a daily driver, so I guess it's mature enough to be used, and I don't even use a DE with all the convenience, I use Sway, coming from i3, and everything I used is working fine, either with an alternative, or relying on XWayland.
>it still has significant shortcomings in hardware support
Apart from Nvidia (which is not that great with Xorg either) I don't know what you're referring to.
> It isn't responsible to suggest it as an alternative
Some mainstream distributions (e.g. Fedora) have defaulted to Wayland, are you calling the maintainers irresponsible?
Xorg already provides a full suite of security protocols that allow fine grained control over every aspect of any application down to the single pixmap via access control hooks.
The fact that nobody really uses them should tell you that the sandboxing craze and whitelisting is mostly if not completely security theater and hostile to the general workflow typical for Desktop applications.
Wayland addresses none of those problems. Wayland is merely just a protocol that can be used to blit some bitmaps together. The protocol says nothing about security except that those problems should be dealt with other protocols which are not part of Wayland.
> Xorg already provides a full suite of security protocols that allow fine grained control over every aspect of any application down to the single pixmap via access control hooks.
One notable exception is OpenSSH, which uses the SECURITY extension with the -X flag (which is their recommended way to use X11 forwarding).
People rarely run untrusted software on FOSS systems. If you can't trust your package manager and your distrobution you have all kinds of problems the least of which is sandboxing applications.
The only untrusted programs I run are Steam games and FPGA tools, and for those I created a separate user account.
The notion that every application must be 100% sandboxed is mostly security theater and will make your life with daily work in the real non-theater world a living nightmare.
Sounds like a hassle. You might as well run it on a separate computer, at least you will be able to use them at the same time. I would prefer better app isolation so I can run everything with the same user, but still hold the apps accountable for what they are doing. OS’s have been designed when the computing paradigm was “computer as large as a building shared by 20 people that write their own software”. That paradigm has changed and the application landscape makes it that we have to use apps from people we don’t know and we can’t reach. We have to make their apps accountable.
It is not a hassle because it is rare to run untrusted software on FOSS systems. Also spinning up a Xephyr window is trivial and not at all like "running it on a separate computer". Setting permissions for each and every installed application in a whitelist model you are proposing would be much more of a hassle. It is already a nightmare on Android where you wave away all kinds of access rights at the point of installing and you just don't care anymore because it becomes really annoying.
The solution to better security is not sandboxing. It is running only trusted application in the first place and making the implementation of those applications simple enough so that many people can understand the source code.
If you define untrusted software as anything not coming from your distro's official package manager, many people run lots of untrusted software on their Linux systems.
Think of PPAs (Debian/Ubuntu/etc), the AUR (Arch/Manjaro), and many other package managers (pip, conda, npm, cargo, etc.).
You have always the option to put programs that you don't trust into a jail. It just shouldn't be mandatory.
Besides, the only good way to solve that problem is namespaces as they are used in Plan9. Sadly Unix/Linux took the wrong turn at some point (probably with the introduction of sockets).
88 comments
[ 3.1 ms ] story [ 152 ms ] threadhttps://www.qubes-os.org/ https://www.whonix.org/
Still, I like the point/aim author is taking.
And where it matters more, hardware compartmentalization.
With the caveat that you need to use secure air-gapped communication, and you probably want to use Qubes on each of the separate machines as well [1].
[1] https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u...
The Tinfoil Chat setup uses optocouplers to enforce one-way data transmission.[0] And one can use inexpensive CD-R and micro SD cards for single-use data transfer. But transferring anything but plain text is dangerous.
0) https://github.com/maqp/tfc
- Scanning QR codes (for example https://air-gap.it/)
- Audio codes (for example https://github.com/romanz/amodem)
Edit: https://air-gap.it/ seems down. But https://github.com/airgap-it is up.
I wonder if one could cut up QR codes, and store pieces separately. If that were done in Gimp or whatever, there could be multiple copies of each piece.
Some of the stuff like code signing is philosophically incompatible with a modular OS where people are often compiling their own binaries, but many of the points raised are good.
This is not a meaningful security feature. If the signature has to be from the manufacturer then you can't so much as write your own shell script, which is useless. That is a cage, not a security measure. But if the user can sign their own binaries then the signature is the equivalent of the execute bit -- you have to tell the system something is executable before it will execute it. Linux has had that forever.
If you download software from a hacked server that serves you malware, the signature check will fail. In contrast, the execute bit can be changed by anyone.
The problem is that you need to get the authentic public key of the software distributor to verify the signature. If an attacker is able to forge the public key, they can easily forge the signature and the signature check will succeed.
Right. If you already have a secure channel to receive the signing key over, you can just use it to receive the software to begin with.
Meanwhile we do have a CA system that lets you download the software via TLS. It's not perfect, but breaking TLS or compromising a CA are not even close to common methods of delivering malware.
Note that the secure channel sometimes has more limited bandwidth. An example would be reading part of your public key over the phone, which is not practical for the actual software. There are other considerations that make using the secure channel for the software itself impractical. For example, you can have many people publish known public keys on their website, so that other people could verify them with some majority voting.
> Meanwhile we do have a CA system that lets you download the software via TLS. It's not perfect, but breaking TLS or compromising a CA are not even close to common methods of delivering malware.
The main risk is not breaking TLS or CAs, but rather compromising the server that you download the software from, and serving malware instead. Indeed, if the same server is used for serving the public key, you don't gain much, because the attacker can just generate their own key pair, sign the malware, and publish their key. But ideally, the public key would not be published from the same server, making an attack more difficult.
In theory, sure. In practice ordinary users are not calling up the software developer and having them read their public key over the phone.
> There are other considerations that make using the secure channel for the software itself impractical. For example, you can have many people publish known public keys on their website, so that other people could verify them with some majority voting.
You could do the same thing with the application binary itself and have them compare hashes.
> But ideally, the public key would not be published from the same server, making an attack more difficult.
You could get the same benefit from publishing only the hash of the software on the separate server. The signature is redundant, and is even worse than the hash because it introduces private key compromise as an attack vector.
The main benefit of signatures is for an app distribution system that needs to distribute multiple apps or updates, so then it can deliver the public key once and reuse it. But now you're talking about the package manager and Linux package managers already do that.
This is not scalable to software updates, which happen much more frequently than (long term) key updates. With hashes you would need to publish a new hash for every update, but with public keys you're fine.
> You could get the same benefit from publishing only the hash of the software on the separate server. The signature is redundant, and is in fact worse than the hash because it introduces private key compromise as an attack vector.
Similarly to the issue I mentioned above, this introduces a hassle because the hash will change every time you update the software, which means you will need to update it. In addition, the system serving the hash/key should have some additional safeguards for updating it (because it's somewhat more sensitive), making the update probably more cumbersome. Could you clarify what attack is possible with keys that is not possible with hashes?
Not everything is perfect, yes moving the toolchain would be nice, but then again, most a community run projects, so the user needs to know about locking their basement as well. Hence the audience is/should be more technical minded anyways.
IMHO another post about comparing apples and oranges leaving out second-level effects. Just an example: Looking for CVE-entries https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=MacOS , https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Linux , https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Windows . We see that MacOS has the fewest and Windows the most CVEs. (So it doesn't matter that Microsoft closes the CVEs quickly and Debian might take some time (haven't really run metrics on that one), there is a huge attack-surface on Windows, compared to Linux and new once have to pop up all the time :D) That isn't looking into severity, because a chaining of medium CVEs might also lead to a compromise as well ,and not everything requires system or root. User might be fine as well. I see a reflection of favoured OS. Only few people use MacOS (some artists, companies streamlining their assets for maintenance and rent,etc.). Windows, on the other hand, was always the big dog on the desktop market. Naturally, maleware authors focus on the biggest market.
A circular saw is a tool, one without a handguard is a bad tool even if it cuts wood well.
./run-saw --yes-without-the-guard
I can understand the mic being always on as a privacy nightmare, but how is this a security nightmare?
That is the price to pay when only technical minded users are the target group.
Consolidation and lack of competition makes for a worse experience.
Also, some of the most common practices on Linux that are claimed to be superior from a security standpoint are just bad. For example, the package manager is very nice, but when you want to install anything that is not in the official repos, your options get just as bad as windows, or worse, despite what many people think. A common recommendation in advanced projects is to add their apt/yum repo to your system, which is not only equivalent to downloading stuff off the internet, it is also you registering them as trusted to deliver updates to your system forever. On Windows, you at least have some anti-virus tool scanning for known malware, so you still have a small chance that you won't be allowed to run some well known malware from years ago.
Also, from what I've seen, custom updaters are still the most common way of delivering updates for Linux outside the distribution-maintained official repo, as most people ship software for many distributions, and maintaining one repo per distribution quickly gets annoying. Ironically, this wouldn't be a problem on Windows or MacOS, if they decided to include a package manager with support for custom repos (the app stores allow side-loading, but do not allow custom upstream, as far as I know).
Strongly disagree. The linux desktop has something like 1% of the marketshare and is far from the lowest hanging fruit. And basic, sane security defaults are plenty good for simple web browsing and emailing.
My grandma used to get calls 2-3 times a month from "Microsoft" and "Comcast" trying to get her to download team viewer and cough up some passwords to Windows 8. She eventually got phished by downloading something dumb via email. I put her on the Ubuntus, with some tweaks, and she's doing fine. 10/10 would do it again.
> For example, the package manager is very nice, but when you want to install anything that is not in the official repos, your options get just as bad as windows, or worse
Grandma ain't installing Steam or an obscure 3rd party metasploit framework -- standard Ubanto repos are fine. She doesn't need rpmfusion to access Office365 emails.
> On Windows, you at least have some anti-virus tool scanning for known malware
Clam-AV is a thing in Linux and works fine -- we used it on mail relays a while back and had decent results. If you're putting trust in the default MS virus protection you're naive.
I don't think anyone is seriously applying those to a desktop system.
They are both based on the Linux Security Module subsystem; which is just too low level to be effective at desktop security. Essentially, they suffer from the same problem as traditional UNIX permissions: no one cares that the attacker cannot access system files. The user's bank account is in their home directory.
[0] https://news.ycombinator.com/item?id=23155269
0: https://xkcd.com/1200/
Ok, who actually uses Scudo (I've certainly never heard of it)?
Bold claims no arguments
But more than "how are we doing vs Apple and Microsoft?" I'd kinda prefer to set the bar a bit higher. Desktop operating systems (all of them, at least with actual users) are just completely architecturally backwards for the reality of our modern security landscape, and what users need from their system. Protection boundaries are still mostly between different users. for most systems that's borderline useless, as there's only one user. Meanwhile every app runs with the full authority of the user and can do anything they can do.
Smartphones are a little better; Android equates "user" with "app" which is at least vaguely useful. But the permissions you end up with are still too coarse grained.
There are better designs out there. For example: web pages can ask the user for a file without getting access to everything the user owns (or at least in the case of Android, all of their files). Why can't native apps do this?
The main issue with using that model for desktop Linux is that apps where not developed with this model in mine. So when an app wants to access your webcam, it tries to do it directly and doesn't ask the OS to grant permission. Similarly when accessing any files.
I guess it's possible in theory to trace any system calls the app makes and accordingly trigger permission requests to the user. Since that didn't happen, maybe it just breaks to many apps to be effective.
BTW, installed apps could create their own UID to isolate themselves, but most developers/distros don't bother doing it. I should not that I did see a significant improvement in running systemd services as separate users, but I rarely see it for user facing apps.
A better option than only using a separate UID is containerization, and things like docker, firejail, bubblewrap, etc, are useful here.
But Linux containers are not considered secure enough (at least compared to VMs). The real gold standard in terms of security is QubesOS, but you pay for that security in performance and ease of use.
https://firejail.wordpress.com/
* Windows page signing is a feature of Authenticode, and applies specifically to "high integrity" kernel drivers. It's basically a niche of normal code signing and should be treated as such.
* Windows just (as in, within the last 6 months) got hardware-backed control flow protection, via Intel CET. They had to add a new debug type (`IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS`) to the debug section to make space for it in the PE format. It'll probably take a few years to become popular, assuming that Microsoft hasn't badly broken it the way they did RFG.
* Modern iOS/Apple mobile hardware is generally a poor contrast: it's homogenous in terms of CPU features in ways that Linux can only dream of, and benefits from Apple's walled garden approach. Linux distros can barely get people to fetch automatic updates; getting them to buy CPUs with hardware CFI features (a la Apple's PAC) is a pipe dream.
- things could be improved if (userland)application maintainers (NOT packaging maintainers) actually bothered to ship apparmor (and/or SElinux) profiles and also properly maintain them for all packages. This will only happen if distributions make them mandatory instead of relying on some 3rd party maintainers.
- it seems that QA in general (and test coverage especially) within Linux distributions isn't very strict (I'm only familiar with Debian/Ubuntu here).
- Haven't seen many services make use of the systemd.exec[1] restrictions in unit files. should be mandatory for all system services to implement these (has to be done by devs not distribution packaging maintainers).
- While it's nice that Debian claims that apparmor is enabled by default now it hides an ugly truth that becomes visible when running `ps auxZ | grep '^unconfined'` ... most applications don't even have a profile and even when you install apparmor-profiles-extra there are only a handful.[2]
- firejail is cool but most people never even heard of it (there is also an overlap in some functionality between apparmor/firejail - and even systemd.exec)
There is always going to be a trade-off between strictness/QA and integrating changes/new packages. but raising the bar can only be possible by having developers maintain these things better and holding them accountable during the distribution packaging. We can't expect the user to figure out what system-calls a process makes so that they can whitelist it themselves.
If Linux on the desktop is ever to compete from a security pov with Apple/Windows then this needs to be done under the hood. While many of my family (including my 70 yro auntie) uses Linux successfully they should never have to know what apparmor/SElinux/etc even is.
[1] https://www.freedesktop.org/software/systemd/man/systemd.exe...
[2] The Debian wiki (https://wiki.debian.org/AppArmor/HowToUse#Enabling_profiles) states: "Beware though: many profiles are not up-to-date and will break functionality in enforce mode, be ready to debug!" <- this shifts the effort to the user (in other words security is available only if one is prepared to implement it by themselves).
I would envision a whitelist system where programs by default can only access files in their own directories, but the file explorer would mediate access to files opened in the program. So if a file is double clicked in explorer, the corresponding program gains access to that file. Likewise, the "Open" feature in the program would have to call the explorer API for the file selection dialog, which would also give it permission. There are certainly lots of edge-cases that would have to be ironed-out.
Another nobrainer is to put permission for network access on a whitelist, in addition to other permissions. It could work similarly to the permissions found on mobile, but it should be possible to install the program anyway without granting it permissions, so that developers don't simply ask for everything as is standard on mobile. Of course, this system would introduce UX headaches for non-technical people which would need to be worked on, but it should at least be an option for security-conscious people.
[1] https://xkcd.com/1200/
Software development is a highly distributed system with many human participants with different (and sometimes conflicting) goals and skills. And to make it effective, you almost always need to reuse software created by many other people that you don't know (which incidentally creates a huge opportunity for supply chain attacks).
In this reality, you get very little assurance about the authenticity and security of anything you use.
It's one of the problems addressed by Wayland
Many people (me included) use Wayland as a daily driver, so I guess it's mature enough to be used, and I don't even use a DE with all the convenience, I use Sway, coming from i3, and everything I used is working fine, either with an alternative, or relying on XWayland.
>it still has significant shortcomings in hardware support
Apart from Nvidia (which is not that great with Xorg either) I don't know what you're referring to.
> It isn't responsible to suggest it as an alternative
Some mainstream distributions (e.g. Fedora) have defaulted to Wayland, are you calling the maintainers irresponsible?
The fact that nobody really uses them should tell you that the sandboxing craze and whitelisting is mostly if not completely security theater and hostile to the general workflow typical for Desktop applications.
Wayland addresses none of those problems. Wayland is merely just a protocol that can be used to blit some bitmaps together. The protocol says nothing about security except that those problems should be dealt with other protocols which are not part of Wayland.
One notable exception is OpenSSH, which uses the SECURITY extension with the -X flag (which is their recommended way to use X11 forwarding).
This is one of the problems addressed by Wayland.
The only untrusted programs I run are Steam games and FPGA tools, and for those I created a separate user account.
The notion that every application must be 100% sandboxed is mostly security theater and will make your life with daily work in the real non-theater world a living nightmare.
Do you also run a separate display server? I'm not convinced a truly malicious executable can be stopped by boundaries between users.
The solution to better security is not sandboxing. It is running only trusted application in the first place and making the implementation of those applications simple enough so that many people can understand the source code.
Besides, the only good way to solve that problem is namespaces as they are used in Plan9. Sadly Unix/Linux took the wrong turn at some point (probably with the introduction of sockets).
Compile from source, use only trusted package managers, and sandbox and compartmentalize when possible.
>Linux distros have no concept of sandboxing
They may be inadequate or need improving, but these concepts are there, if rarely used by default.
>Any app running under Xorg can see the contents of any other app runing under Xorg.
There are ways to prevent this without saying "Wayland".
>The only good sandoxing API provided by the Linux kernel is seccomp-bpf, and the only program that uses it is Google Chrome/Chromium.
The very link to the wikipedia entry for seccomp shows otherwise...
>Also a friendly reminder that Debian is always behind on CVEs, and I'm sure that most distros don't fare any better.
This is a good point, and one of the reasons I think that the future will belong to rolling release style distros with a faster CVE cycle.
Just the few things that stood out to me, not a piece by piece analysis.
Calls OpenBSD "Masturbating Monkeys" for the security mitigations.
Thanks Linus..good job
Torvalds calls OpenBSD "Masturbating Monkeys"
for their mitigations,
Thanks Linus