How to disable this feature:
https://tinyapps.org/blog/202010210700_whose_computer_is_it....
And a humorous guide on disabling protections like code signing and notarization:
https://www.naut.ca/blog/2020/11/13/forbidden-commands-to-li...
https://tinyapps.org/blog/202010210700_whose_computer_is_it....
And a humorous guide on disabling protections like code signing and notarization:
https://www.naut.ca/blog/2020/11/13/forbidden-commands-to-li...
@grishka Edit because I'm rate limited:
I've not seen anything that does executable validation for linux and actually works. Needs lots of kernel support. See the response from the old DigSig author: https://stackoverflow.com/questions/1732927/signed-executabl...
You can check binary signatures on disk (tripwire) but that is extremely tiresome to maintain and does not prevent straight loading of shellcode into memory.
More recently: https://lwn.net/Articles/733431/
Signed kernel modules is on its way though: https://www.kernel.org/doc/html/latest/admin-guide/module-si...
I guess that would be a place to start for implementing SIP...
/usr/bin/vim was installed by my package manager, but there's no guarentee the version I'm running matches the version that was installed. Now in debian there is a file which has a checksum of the version the package installed, but that's not checked on execution, nor is it itself signed (so the process that replaced vim could just as easilly replace the checksum, or the process that checks the checksum)
ChromeOS uses dm-verity to verify the root partition at runtime, similar to Mac OS's signed system volume.
I won't disable SIP and I'll avoid installing Google Chrome on my new Macs, if possible.
Given the choice between (a) a corporate OS that requires me to perform some amount of work to "turn off" some "features" the corporation has enabled and (b) a non-corporate OS that requires me to perform some amount of work to "turn on" the "features" that I want to use, I prefer (b).
Most of them won't even care about sending too much data to a company if that's the price to have the same device everyone else is using in their industry...
Came here to say that.
> Most of them won't even care about sending too much data to a company if that's the price to have the same device everyone else is using in their industry...
I do, I truly do care. So much that I'm looking at open-source/Linux options, at least for my home projects. Doesn't look very bright on the video side, but DaVinci Resolve is at least available for Linux. Rawtherapee is getting there with local adjustments as we speak. Darktable has lots of power but terrible UX.
People today, even more so than in the 2000's, have multiple computers. Would it still be feasible to have a Mac used for {music, cinema, graphics} that is not connected to the internet. Certainly one would have other computers that were connected to the internet and moving files between computers on the local network, preferably via Ethernet, is much faster.
But the point of me telling personal stories is not to suggest anyone could/should do the same things; on the contrary, it is to illustrate that "one size does not fit all". Today's Apple chooses for the user, rather than letting the user choose.
While most of Linux's audience (and probably practically all of NetBSD's) is rather technically inclined and could possibly be expected to turn on the security features as they need them, most of Windows' and macOS's audience will very likely have no idea that there is even an option to do this.
Also, software companies would probably take the easy route and just assume that since those features aren't enable by default, most people don't enable them and develop their software in a way which could be incompatible with them.
So I think that for an OS like macOS, where most people flock "because it just works and has no viruses", strict defaults are a sane choice. Having people go through hoops and click through warning messages would probably also push companies to better design their software.
In the end, I think the best way is for such features to be the default setup. But those OSs need to have an "escape hatch" for someone who actually wants those features disabled and actually understands the risks of disabling them. While macOS does (for the moment) have this hatch, it looks maybe /too/ complex. But then I think the difficulty of the exercise is in setting the "correct" level of complexity for this operation.
So the right path for consumer OS is ‘sound opinions, easily changed’.
Even technical users are going to differ in the sets of opinions they hold and are qualified to hold. I care about which Python I have installed. The virtual memory manager? Not so much. Someone else might, though.
The list is really disappointing.
actually default on, is not a problem if it is easy to turn it off in that case. if apple would have had a button to turn it off, we would be fine.
I don't believe the defaults related to this issue are a problem; its the lack of transparency about this, coupled with it being difficult to change this. Probably every update you gotta fix that. That's akin to running a Hackintosh. And we all know macOS is moving towards iOS; not Hackintosh/PC.
A more common use case for this kind of choice is corporate laptops. They usually set up their own policy on the laptop before handing it to employees for good reason. Firewalls are especially necessary to avoid leaking confidential information.
On the server, there’s a reason Amazon built Firecracker and Google built gVisor instead of just using the Linux sandboxing primitives. I think calling them “industrial grade” is pushing it when they’re rarely used as the first line of defense against code that is expected to be actively hostile.
If an application uses Gtk+3 or Qt5 then portals will be used automatically for Open/Save dialogs:
https://docs.flatpak.org/en/latest/sandbox-permissions.html#...
I agree with the thrust of you comment though, outside the webbrowser, proper sandboxing a barely used outside web browsers. However, I think the problem is as much social as technical. Every time Flatpak comes up, it mostly gets hostile reactions.
The situation is rather unfortunate. A lot of people believe that Linux is more secure than other operating systems, but in practice the Linux desktop is far less secure than e.g. macOS, iOS/iPadOS, or Android.
And no, you aren't safe because it is open source software. Sandboxing also protects against unknown vulnerabilities in open source software.
actually firecracker is not a sandbox. it's basically qemu/libvirt and a minimal implementation of devices. it's qemu-kvm with a http interface and way less devices.
the reason why they rewritten qemu-kvm is because qemu-kvm contains a lot of code that is not needed and is way more bug prone. and also loading a kernel is way faster in firecracker since they optimized the kernel loading code.
The reason is that Firecracker is a virtual machine, and Linux containers and sandboxing primitives are not meant to be used for virtual machines.
Pointing at Snap and Flatpak's "sandboxes" is disingenuous when they're notorious for having sandboxing as an after thought to app distribution.
When I say industrial grade, I mean that the sandboxing and isolation primitives that are used in industry are those that are either provided in the kernel, or are deployed as part of a standard Linux server deployment.
I point to snap and flatpak because outside of browsers they are AFAICT the only attempts to sandbox user applications on Linux. It would be disingenuous if there were some other apps or distribution channels doing a better job that I hadn’t mentioned, I’d love to hear of some.
My point: opting out should be much, much easier.
What could be easier?
Most consumers don't care about security, making it easy to disable just opens the floodgates of their systems.
EDIT: clarity
[1]: https://github.com/coreutils/coreutils/commit/34e3ea055721ec...
"How do I do X? Just run this as root." Sometimes slightly disguised, but more often not.
Fighting the OS you are running is an uphill battle that gets tiresome real quick.
Most users will say yes.
Technical ones at least can say no.
Easier than setting up bluetoooth.