"Snaps are containerised software packages that are simple to create and install. They auto-update and are safe to run."
I hate this and I am pretty sure they are not safe to run. Especially if they prompt you for third-party credentials. 🤦
Conversation
Replying to
Snap permissions are generally automatically enabled and the approval process is primarily by Canonical rather than requesting it from the user:
snapcraft.io/docs/permissio
It's also designed in a very coarse and problematic way. Not a good system. Still better than Flatpak though.
2
My understanding is that it mostly is decent solving the "self-contained app" problem, but has a broken sandbox model tacked on. If you just provide your own sandbox it should be good.
1
It's the failed attempt at providing a privacy/security model that's the problem. It might be better than Snap and other alternatives if you ignore all that. They made it a big part of it though. There are also APIs tied to it. They ported Chromium to using Flatpak sandbox APIs.
1
They ended up building things in a way where they end up requiring applications to target their own APIs but a lot of it is designed poorly. It leaks a ton of weird implementation details and a lot is misguided. They're doing a lot of it without looking at iOS, Android, etc.
1
I think it's pretty silly to basically work towards spending years of work re-creating the Android 4.4.x sandbox and permission model but without most applications actually using it. Also no one to force apps to do yearly migrations to a stricter sandbox / permission model.
1
The Android sandbox and permission model is a dead end, built on NSA Linux rather than namespaces.
2
It does use namespaces. They don't offer a way to do the things that it does with SELinux. SELinux is an implementation detail not expose to app developers. It could be any other LSM. It's just how the fine-grained, hard-wired policy in the OS is written. It's not for app devs.
Namespaces and uids/gids are an implementation detail too. There are APIs like isolatedProcess for making an internal sandbox within an app and the way that uses uids/gids, SELinux, etc. is just an implementation detail. Apps can't do anything with SELinux policies / labels, etc.
1
Android SELinux policy is 100% static. There are no dynamic changes, booleans, etc. It's only the OS responsible for putting things into the right domains, etc. Could be replaced by a theoretical equally capable LSM by converting policies and apps wouldn't notice any change.
1
Show replies
The stuff you can do with SELinux or LSMs is not stuff that makes sense to do.
1
Then you give up on being able to filter access to kernel APIs like procfs, sysfs, debugfs, perf events, driver ioctls, etc. along with enforcing the security model between the sandboxes via static policy instead of only being something derived dynamically at runtime from code.
2
Show replies