this post was submitted on 04 Feb 2022
15 points (85.7% liked)
Security
5005 readers
2 users here now
Confidentiality Integrity Availability
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Good article. Thank you. You make some excellent points.
I agree that source access is not sufficient to get a secure software and that the many-eyes argument is often wrong. However, I am convinced that transparency is a requirement for secure software. As a consequence, I disagree with some points and especially that one:
In my experience as a developer, the vast majority of vulnerabilities are caught by linters, source code static analysis, source-wise fuzzers and peer reviews. What is caught by blackbox (dynamic, static, and negative) testing, and scanners is the remaining bugs/vulnerabilities that were not caught during the development process. When using a closed source software, you have no idea if the developers did use these tools (software and internal validation) and so yeah: you may get excellent results with the blackbox testing. But that may just be the sign that they did not accomplish their due diligence during the development phase.
As an ex-pentester, I can assure you that having a blackbox security tools returning no findings is not a sign that the software is secure at all. Those may fail to spot a flawed logic leading to a disaster, for instance.
And yeah, I agree that static analysis has its limits, and that running the damn code is necessarry because UT, integrations tests and load tests can only get you so far. That's why big companies also do blue/green deployments etc.
But I believe this is not an argument for saying that a closed-source software may be secure if tested that way. Dynamic analysis is just one tool in the defense-in-depth strategy. It is a required one, but certainly not a sufficient one.
Again, great article, but I believe that you may not be paranoid enough 😁 Which might be a good thing for you 😆 Working in security is bad for one's mental health 😂
Linters are a great thing I should've mentioned, esp. ones like ShellCheck. The phrase "low-hanging fruit" has been doing a lot of heavy lifting. I should mention that.
I talked a lot about how to determine if software is insecure, but didn't spend enough time describing how to tell if software is secure. The latter typically involves understanding software architecture, which can be done by documenting it and having reverse engineers/pentesters verify those docs' claims.
It's getting late (UTC-0800) so I think I'll edit the article tomorrow morning. Thanks for the feedback.
@X_Cli@lemmy.ml I updated the post to add a bit to one of the counter args, with a link to your comment. Here's a diff
Thank you <3
I was very explicit that the two types of analysis are not the same. I repeatedly explained the merits of source code, and the limitations of black-box analysis. I also devoted an entire section to make an example of Intel ME because it showed both the strengths and the limitations of dynamic analysis and binary analysis.
My point was only that people can study proprietary software, and vulnerability discovery (beyond low-hanging fruit typically caught by e.g. static code analysis) is slanted towards black-box approaches. We should conclude that software is secure through study, not by checking the source model.
Edit: I liked that last sentence I wrote so I added it to the conclusion. Diff.
Lots of FLOSS is less secure than proprietary counterparts, and vice versa. The difference is that proprietary counterparts make us entirely dependent on the vendor for most things, including security. I wrote two articles exploring that issue, both of which I linked near the top. I think you might like them ;).
Now, if a piece of proprietary software doesn't document its architecture, makes heavy use of obfuscation techniques in critical places, and is very large/complex: I'd be very unlikely to consider it secure enough for most purposes.
Sure you can. I went over several example.
I freely admit that this leaves you dependent on a vendor for fixes, and that certain vendors like oracle can be horrible to work with (seriously check out that link, it's hilarious). My previous articles on FLOSS being an important mitigation against user domestication are relevant here.
I can't confidently assert anything with complete certainty regardless of source model, and you shouldn't trust anyone who says they can.
I can somewhat confidently say that, for instance, Google Chrome (Google's proprietary browser based on the open-source Chromium) is more secure than most Webkit2GTK browsers. The vast majority of Webkit2gtk-based browsers don't even fully enable enable sandboxing (
webkit_web_context_set_sandbox_enabled).I can even more confidently say that Google Chrome is more secure than Pale Moon.
To determine if a piece of software invades privacy, see if it phones home. Use something like Wireshark to inspect what it sends. Web browsers make it easy to save key logs to decrypt packets. Don't stop there; there are other techniques I mentioned to work out the edge cases.
Certain forms of security are necessary for certain levels of privacy. Other forms of security are less relevant for certain levels of privacy, depending on your threat model. There's a bit of a venn-diagram effect going on here.
Sure, but don't stop at whitebox methods. You should use black-box methods too. I outlined why in the article and used a Linux vuln as a prototypical example.
You're making a lot of blanket, absolute statements. Closed-source software can be analyzed, and I described how to do it. This is more true for closed-source software that documents its architecture; such documentation can then be tested.
I am in full agreement with this paragraph. There is a mind-numbing amount of proprietary shitware out there. That's why, even if I was only interested in security, I wouldn't consider running proprietary software that hasn't been researched.
Windows Enterprise and macOS are ahead of Linux's exploit mitigations. Madaidan wasn't claiming that Windows and macOS are the right OSes for you, or that Linux is too insecure for it to be a good fit for your threat model; he was only claiming that Windows and macOS have stronger defenses available.
QubesOS would definitely give Windows and macOS a run for their money, if you use it correctly. Ultimately, Fuchsia is probably going to eat their lunch security-wise; its capabilities system is incredibly well done and its controls over dynamic code execution put it even ahead of Android. I'd be interested in seeing Zircon- or Fuchsia-based distros in the future.
When it comes to privacy: I fully agree that the default settings of Windows, macOS, Chrome, and others are really bad. And I don't think "but it's configurable" excuses them: https://pleroma.envs.net/notice/AB6w0HTyU9KiUX7dsu
Here's an exhaustive list of the proprietary software on my machine:
That's it. I don't even have proprietary drivers. I'm strongly against proprietary software on ideological grounds.
The server, desktop, and mobile computing models are all quite different. The traditional desktop model involves giving programs the same user privileges and giving them free reign over all a user’s data; the server model splits programs into different unprivileged users isolated from each other, with one admin account configuring everything; the mobile model gives programs private storage and ensures that programs can’t read each others’ data and need permission to read shared storage. Each has unique tradeoffs.
macOS has been adopting safeguards to sandbox programs with fewer privileges than what's available to a user account; Windows has been lagging behind but has made some progress (I'm less familiar with the Windows side of this). On Linux, all modern user-friendly attempts to bring sandboxing to the desktop (Flatpak and Snap are what I'm thinking of) allow programs opt into sandboxing. The OS doesn't force all programs to run with minimum privileges by default having users control escalating user-level privileges; if you
chmod +xa file, it gets all user-level privileges by default. Windows is...somewhat similar in this regard, I admit. But Windows' sandboxing options--UXP and the Windows Sandbox--are more airtight than Flatpak (I'm more familiar with Flatpak than Snap, as I have some unrelated fundamental disagreements with Snap's design).I think Flatpak has the potential to improve a lot: it can make existing permissions enabled at run-time so that filesystem-wide sandboxing only gets enabled when a program tries to bypass a portal (most of the "filesystem=*" apps can work well without it, and some only need it for certain tasks), and the current seccomp filter can be made a "privileged execution" permission with the default filters offering fine-grained ioctl filtering and toggleable W^X + W!->X enforcement. The versions of JavaScriptCore, GJS, Electron, Java, and LuaJIT used by runtimes and apps can be patched to run in JITless mode unless e.g. an envvar for "privileged execution" is detected. I've voiced some of these suggestions to the devs before.
My favorite (and current) distro is Fedora. If Flatpak makes these improvements, Fedora lands FS-verity in Fedora 37, Fedora lands dm-verity in Silverblue/Kinoite, and we get some implementation of verified boot that actually lets users control the signing key: I personally wouldn't consider Fedora "insecure" anymore. Though I'd still find it to be a bit problematic because of Systemd. I wasn't convinced by Madaidan's brief criticisms of Systemd; I prefer this series of posts that outlines issues in Systemd's design and shows how past exploits could have been proactively (instead of reactively) avoided:
Systemd exposes nice functionality and I genuinely enjoy using it, but its underlying architecture doesn't provide a lot of protections against itself. The reason I bring it up when distros like Alpine and Gentoo exist is that the distro I currently think best combines the traditional desktop model with some hardening--Fedora Silverblue/Kinoite--uses it.
QubesOS is based on Linux, but it isn't in the same category as a traditional desktop Linux distribution. Like Android and ChromeOS, it significantly alters the desktop model by compartmentalizing everything into Xen hypervisors. I brought it up to show how it's possible to "make Linux secure" but in doing so you'd deviate heavily from a standard distribution. Although Qubes is based on Linux, its devs feel more comfortable calling it a "Xen distribution" to highlight its differences from other Linux distributions.
I only brought this up in response to the bad-faith argument you previously made:
I don't use any closed-sourced tools on my personal machine beyone hardware support, emulated games, and webapps I have to run for online classes. Since you seem to be arguing in bad faith, I don't think I'll engage further. Best of luck.