[sneak]

I still think the new (since Catalina) macOS per-app, per-directory permissions is critical to avoid being vulnerable to ransomware. Not everything that runs as my uid should have access to everything my posix permissions allow, especially ~/Documents and such.

Dockerizing every GUI app I run is going to be a pain, otherwise.

[markosaric]

For Linux, there's Flatseal for all Flatpak apps. Easy and simple GUI that allows you to set permissions for individual apps including network access, microphone/camera access and directories access.

[1over137]

It'd be nice to have both. But with Big Sur crippling Little Snitch, like rdn, I too am looking to bail from Apple. One can be selective in the apps one chooses to install, but one can no longer block Apple's telemetry and cloud stuff. Pity. I've been Apple-only since the Apple IIgs.

[miles]

> one can no longer block Apple's telemetry and cloud stuff

Here are two workarounds:

Install Little Snitch 4.6 instead of 5: https://www.obdev.at/support/littlesnitch/245913651253917

Hacky method to disable Apple's exceptions: https://tinyapps.org/blog/202010210700_whose_computer_is_it....

[sneak]

That first link is gold! The second one is bad because you can't disable the signed system (readonly) root without disabling FileVault and leaving it disabled, which is a showstopper for me.

Will 4.x be installable on ARM? I imagine the kernel extension needs to match the arch of the kernel, and because ARM macs don't run anything before Big Sur, I imagine only 5.x has ARM builds available?

[XorNot]

Isn't this pretty much SELinux?

[hxtk]

Sort of. By default, most SELinux systems have users logged in as `unconfined_u`, which as the name implies receives nearly no confinement.

Any application that doesn't have a specific policy written for it will either inherit the domain that spawned it (in this case, `unconfined_u:unconfined_r:unconfined_t:s0:c0.c1023`) or receive some default domain (e.g., `system_u:system_r:unconfined_service_t` for systemd services, `initrc_t` for init daemons, etc.)

Because of this, most applications will end up inheriting the user's domain, which again is `unconfined_t` by default under the targeted policy.

Lots of common applications have policies so that they transition to their own domain and then execute under customized policy, but it's less common for user applications (and especially user applications that are not system tools) than for daemons so it's not generally safe to assume you're protected by selinux when going about typical user tasks.

However, writing SELinux policy isn't that hard (although it's a bit harder than just `audit2allow` to do it well) and it's a perfectly reasonable project for an afternoon to write a policy for an unconfined application you use, if you're willing to spend some time up front learning about SELinux policy language.

[XorNot]

You can disable the unconfined_u user though, it's just stricter then the normal "targeted" policy which is common today. What I'm saying is we don't need a new technology here, we actually have the technology we just need to deploy it properly.

SELinux provides all the tools we need to implement the guarantees, just Linux distros don't currently have a stance on how they want to expose such a policy option.

[Jnr]

How about Firejail?