Very presumptuous of me to say this, but I wonder if the "brick wall" is a non-technical PR type who has been put in the center of many very technical questions, and has realized that his/her boss doesn't yell at him/her if he/she simply doesn't respond very much to external queries.
It can be hard when your job mostly consists of talking to extremely knowledgable people (such as many researchers in this field are) without yourself being at least broadly knowledgable on nearly everything technical.
I don’t understand your point. They are talking about “Apple Product Security”. If the person employed there is as you describe then it’s first of all an outrage that Apple do not hire sufficiently competent people for these types of critical positions, and secondly it does not exonerate this hypothetical person from the duty of escalating and understanding the impact.
Hmm.. that is not what I meant. Rephrased it to "Any suggestions which distro takes security serious?" now.
Since it seems that Debian has decided to not patch Chromium for months now, how do I know they won't do the same for Firefox at some point? Or any other software in their repos?
I would prefer a distro which promises to keep all software in their repos secure for a certain amount of time. Even if that means having fewer packages than other distros.
Why don't they keep Chromium up to date like they do with Firefox? Ubuntu (to my knowledge) exempts browsers from their LTS policy because of security fixes being bundled with feature updates.
If bang up to date software is what matters to you, Debian's the opposite of what you want. Maybe try Arch, which operates a rolling release approach and is well known for following the bleeding edge. FWIW, its firefox [1] and chromium [2] packages are currently at the latest versions and were both published on the day of the upstream release.
I'm not surprised that Linux Mint has egregious security issues, the developers are paid nothing to make it and there's basically no corporate incentive to secure it. On the other hand, Apple and Google have quite literally trillions of dollars at their disposal. Their security teams ought to be the largest and most advanced in the world, but they aren't. They're criminally understaffed and have their hands tied by upper management when it comes to accepting help from third-parties like Corellium who actually know what they're doing. Instead, everyone shuts each other out to pretend like they know what they're doing, only to get clowned on when some 13-year-old takes down their homepage with SQL injection.
I'm tired of pretending like security is anything other than theater and optics at this point. You either accept humility and design transparent software, or embrace complexity and let the machine consume you. The business of building software has started shifting to the latter paradigm, and now they're paying the price for it. If we're lucky, we might see a reprieve of the late-80s within the decade, where the internet is saturated with buggy and proprietary servers ripe for the hacking.
Debian can't be held responsible for flaws in Chromium can they? Wouldn't those same issues exist on all distros with the same version of Chromium? Doesn't the distro just package what they can as best they can?
I am confused about your question. Can you elaborate? Distros usually provide patches for known security holes in their repos. Why would one not hold them responsible to do so?
The burden is entirely Debian's choice. They want to mess around backporting fixes. They could just package upstream's releases, but that would break their choice of stability model. The downsides of that choice of model is nobody's fault but their own.
Debian just pulls in upstream updates for Chromium, since it is basically impossible to provide the normal patch backport method of security updates for modern web browsers, including Chromium and Firefox.
The whole maintainer model exists in Debian because Debian tries to do its own maintenance on packages, even if the original developers are unwilling to accept the fix back.
Chromium and Firefox are sort of monster code bases, though, it’s not surprising to me that distros are reluctant to change it in key ways.
No, software developers and package maintainers do. A distro is where it goes all together and normally under a license.
Even licenses are different across packages in a repo, they normally all have a pretty clear wording how much you can hold responsible them for that (hint: no warranty, no fitness for a particular purpose).
Read it before use and think first, e.g. how that software comes to life and is managed / maintained. Debian =/= Apple.
The license states "Provided AS-IS". There is no right to damn the distributor to not make it not available (and as far as this is Chromium not even the project) - just that.
Foxboron on the Arch team is very serious about security. Check out the Security page on the archwiki for guidance on building your own hardened Arch system.
This isn't quite true. There are some X11 screen lockers (maybe only GNOME?) that coordinate with the login manager so that a crash just leads to a restarted login manager.
...but yes, most X11 screen lockers have this flaw.
On the "base install". OpenBSD's attitude is, if you install insecure 3rd party code, it's on you.
QubesOS, based on Xen hypervisor, provides compartmented security: a hole in an app need not provide access to anything else. You have multiple mostly long-running VMs for different roles. Hardware access is managed in VMs that do not run app code. 16GB RAM is just barely enough, and apps get no access to a GPU. But it's solid and mature. The 4.1 release, due someday, has had a lot of UX attention.
SpectrumOS is an an attempt at lighter-weight security. Based on NixOS, apps run in a minimal, temporary VM spun up just for the app, sub-second, for experience more like Docker than Virtualbox. Still very much under development. Donate to Alyssa Ross on Github to accelerate dev work.
This is the best answer. Qubes OS is really the only practical way to run Linux in a secure manner right now. Its isolation features are not just useful for security, it makes experimentation really easy as one of never has to worry about messing up the installation.
Spectrum may be an option in the future, and I really hope it succeeds.
Fedora Silverblue is becoming interesting as well, especially with "Toolbox" a tool that lets you quickly spin up relatively isolated containers as long-lived development environments, separated from the main OS-installation.
Silverblue has some promise. However, at this point, security is not a consideration. Toolbox is nice, and gives some of the convenience that you get from Qubes, but unfortunately none of the security.
Code running in a toolbox container still has access to the user's home directory, and based on the bug reports on the topic, there are no plans to address this limitation.
> Code running in a toolbox container still has access to the user's home directory, and based on the bug reports on the topic, there are no plans to address this limitation.
I knew it could have access, but damn, I expected that would be optional. That's disappointing.
It's a real shame. With some additional hardening, it could achieve a nice balance between convenience and security.
I should add that QubesOS has the only secure X environment ever. The central VM ("dom0") controls the actual screens and input devices. Each VM runs its own X server, writing to a raw memory buffer. dom0 copies window contents from those buffers to windows on the real screens, and forwards input from events that address a window to (only) the right VM.
SpectrumOS is built around Wayland instead.
Microphone and camera streams are, likewise, forwarded from dom0 to whatever VM you select to receive them, if any. USB gadgets you plug in, similarly, may be operated by the VM of your choice.
> If you cannot trust Debian - whom can you trust?
When did Debian become a model of trustworthiness regarding software security?
We are talking about one of the distributions applying the most patches to its repository for reasons which are often dubious and with little general oversight.
Debian is famous for being run by volunteers but it has always been kind of dodgy. We are talking about the distribution which made it's version of openssl vulnerable by breaking its random generator in order to silence a Valgrind warning.
But neither GCC nor Clang did and the diff applied by Debian actually triggered the bug without fixing anything. The fact that OpenSSL also happened to be a terrible piece of software doesn't exonerate Debian.
I have to disagree: OpenSSL shares the blunt of the blame. (Whilst saying that, it doesn’t help that both projects are under resourced.) The Debian maintainer contacted upstream about the underlying issue, but received no response. Nor did the patch break any tests.
We've also seen since then just how broken OpenSSL was generally, with Heartbleed. And why did OpenSSL have its own RNG that invoked undefined behaviour, when it could just read from /dev/random?
Moreover, in hindsight, we have a much better understanding of undefined behaviour than we used to. Undefined behaviour is not “occasionally the optimiser might bite you” but “sometimes you'll get (un)lucky in that it’ll appear to work. Don’t do it”.
"... whom I thought they would take security very serious."
I have always wondered why "tech" companies constantly make statements on their websites such as "We take security very seriously". (Same for privacy.) There is really nothing to back them up. Its just words, no evidence. Of course the companies are all copying each others statements, but perhaps there is some science behind these words, perhaps these statements really do work. Readers actually believe them.
Its like they can make "promises" without ever actually having to deliver anything, and people actually believe they are getting some sort of "deliverable". Occasionally theres a brief "wake-up" call and then their users go back the illusion.
Being "shocked" it seems is short-lived. No doubt the "tech" companies have figured this out. I can remember when people were "shocked" about all the vulnerabilities in Windows. Those days are gone. Now there is no "shock" at all. Its expected.
Reminds me of the reports of internal communications at Facebook that showed how Sandberg and colleagues were seeking to "normalise" data breaches.
Debian security support is provided by volunteers (except for the LTS releases), it is a hard job just to track all the known security issues out there, let alone fix the known issues, let alone find all the unknown issues or harden toolchains and packages against unknown issues. If you would like to help improve Debian security support, please get involved.
Question: aren't these objects files on the filesystem since MacOS is Unix-based? In other words, have they forgotten to `chmod` them, or are they just plain objects and the checks are high-level abstractions each developer has to implement manually?
64 comments
[ 28.2 ms ] story [ 3018 ms ] thread>The Register asked Apple to comment, but the brick wall did not respond.
Seems about right.
It can be hard when your job mostly consists of talking to extremely knowledgable people (such as many researchers in this field are) without yourself being at least broadly knowledgable on nearly everything technical.
Did you know that you can bypass the lockscreen on Linux Mint by plugging in an external monitor?
https://github.com/linuxmint/cinnamon/issues/9123
Did you know that when you use Chromium on an up-to-date Debian stable, it has over 100 unpatched security holes?
https://security-tracker.debian.org/tracker/status/release/s...
If you cannot trust Debian - whom can you trust? Any suggestions which distro takes security serious?
Prevent physical access, install only ssh for external access and run Sshguard. And use Firefox as a browser.
Since it seems that Debian has decided to not patch Chromium for months now, how do I know they won't do the same for Firefox at some point? Or any other software in their repos?
I would prefer a distro which promises to keep all software in their repos secure for a certain amount of time. Even if that means having fewer packages than other distros.
[1] https://archlinux.org/packages/extra/x86_64/firefox/ [2] https://archlinux.org/packages/extra/x86_64/chromium/ (latest update was 24th sept, but there was also a 94 version published on 21st, the day of the stable release)
I'm tired of pretending like security is anything other than theater and optics at this point. You either accept humility and design transparent software, or embrace complexity and let the machine consume you. The business of building software has started shifting to the latter paradigm, and now they're paying the price for it. If we're lucky, we might see a reprieve of the late-80s within the decade, where the internet is saturated with buggy and proprietary servers ripe for the hacking.
On their blog they say:
https://blog.linuxmint.com/?p=1851Chromium is a huge beast of code, should Debian maintainers be debugging and coding patches to various packages?
I think we can't expect the distro to fix the security issues in everything. It's upstream responsibility to handle their own CVE.
Perhaps Google should have one FTE for each major distro to help keep that beast of a codebase up to the standard these threads seem to expect.
It's a heavy burden to place on Debian - and I don't think it's fair to expect them to have eg Chromium and the 10-hundred other packages perfect.
Debian is fscking awesome, they are doing amazing work. Hip Hip Hooray!!
Chromium and Firefox are sort of monster code bases, though, it’s not surprising to me that distros are reluctant to change it in key ways.
Even licenses are different across packages in a repo, they normally all have a pretty clear wording how much you can hold responsible them for that (hint: no warranty, no fitness for a particular purpose).
Read it before use and think first, e.g. how that software comes to life and is managed / maintained. Debian =/= Apple.
Not sure what that has to do with licenses.
...but yes, most X11 screen lockers have this flaw.
OpenBSD.
QubesOS, based on Xen hypervisor, provides compartmented security: a hole in an app need not provide access to anything else. You have multiple mostly long-running VMs for different roles. Hardware access is managed in VMs that do not run app code. 16GB RAM is just barely enough, and apps get no access to a GPU. But it's solid and mature. The 4.1 release, due someday, has had a lot of UX attention.
SpectrumOS is an an attempt at lighter-weight security. Based on NixOS, apps run in a minimal, temporary VM spun up just for the app, sub-second, for experience more like Docker than Virtualbox. Still very much under development. Donate to Alyssa Ross on Github to accelerate dev work.
Spectrum may be an option in the future, and I really hope it succeeds.
Code running in a toolbox container still has access to the user's home directory, and based on the bug reports on the topic, there are no plans to address this limitation.
I knew it could have access, but damn, I expected that would be optional. That's disappointing.
It's a real shame. With some additional hardening, it could achieve a nice balance between convenience and security.
SpectrumOS is built around Wayland instead.
Microphone and camera streams are, likewise, forwarded from dom0 to whatever VM you select to receive them, if any. USB gadgets you plug in, similarly, may be operated by the VM of your choice.
Slide 43 is worrying.
What do you expect when you use Debian stable? Precisely people choose Debian stable because it gets no updates. (I'm only half kidding)
When did Debian become a model of trustworthiness regarding software security?
We are talking about one of the distributions applying the most patches to its repository for reasons which are often dubious and with little general oversight.
Debian is famous for being run by volunteers but it has always been kind of dodgy. We are talking about the distribution which made it's version of openssl vulnerable by breaking its random generator in order to silence a Valgrind warning.
We've also seen since then just how broken OpenSSL was generally, with Heartbleed. And why did OpenSSL have its own RNG that invoked undefined behaviour, when it could just read from /dev/random?
Moreover, in hindsight, we have a much better understanding of undefined behaviour than we used to. Undefined behaviour is not “occasionally the optimiser might bite you” but “sometimes you'll get (un)lucky in that it’ll appear to work. Don’t do it”.
I have always wondered why "tech" companies constantly make statements on their websites such as "We take security very seriously". (Same for privacy.) There is really nothing to back them up. Its just words, no evidence. Of course the companies are all copying each others statements, but perhaps there is some science behind these words, perhaps these statements really do work. Readers actually believe them.
Its like they can make "promises" without ever actually having to deliver anything, and people actually believe they are getting some sort of "deliverable". Occasionally theres a brief "wake-up" call and then their users go back the illusion.
Being "shocked" it seems is short-lived. No doubt the "tech" companies have figured this out. I can remember when people were "shocked" about all the vulnerabilities in Windows. Those days are gone. Now there is no "shock" at all. Its expected.
Reminds me of the reports of internal communications at Facebook that showed how Sandberg and colleagues were seeking to "normalise" data breaches.
https://security-tracker.debian.org/tracker/data/report https://www.debian.org/security/audit/ https://www.debian.org/doc/manuals/developers-reference/pkgs... https://wiki.debian.org/Hardening https://wiki.debian.org/Hardening/RepoAndImages https://wiki.debian.org/Hardening/Goals https://www.debian.org/intro/help
Shocker
I didn't know that wasn't the default. I wouldn't really class this as an urgent security hole.
https://news.ycombinator.com/item?id=28637276