71–80 of 89 posts
Earlier quoted context omitted.
> The principle of Linux was and still is to give tools and have users use them. A circular saw is a tool, one without a handguard is a bad tool even if it cuts wood well.
I found that a 14" circular saw with the guard removed was a great tool. It demanded a lot of respect - much like some tools in Linux. ./run-saw --yes-without-the-guard
What about firejail?
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. Untrust…
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 b…
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.
> 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 executa…
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 e…
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.
> 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 executa…
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.
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 wit…
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.).
Earlier quoted context omitted.
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 e…
> 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 metho…
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.
Earlier quoted context omitted.
> 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 metho…
> 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 impractic…
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.
Earlier quoted context omitted.
> 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 impractic…
> 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 imp…
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?
What about firejail?
elaborate -- what is this tool and why should i consider it?