Just imagine you need a container for the calculator.....

OpenBSD went that route, and when they introduced pledge(2) and later unveil(2), they've applied these to every single program in the base system (over the course of a single release cycle!).

There's absolutely zero reason for bc(1) to accept network connections, or for grep(1) to execve(2) into arbitrary programs. But both of these programs need to process and interpret arbitrary input, which makes them potential targets for exploits.

You don't technically "need" security, just like you don't "need" seatbelts... until you actually are in an accident.

https://man.openbsd.org/pledge; https://man.openbsd.org/unveil

you really compare something like pledge and unveil with flatpack and snap's? Completely different goal's...

I don't think the security goals are that different, but you've asked why would I want to sandbox a calculator. Well - why would I not want that?

Look, you gave the openbsd example, and that's the right way to do it.

Flatpack's are for packaged software-deployment, those are two different things.

Why the need for a sandbox if you could do it much cleaner with things like pledge? But in typical linux fashion, just put another layer on top the pile of garbage so it stop's to stink for a while.

>Well - why would I not want that?

Then please start with the most obvious application sometimes called kernel.

Instead of rigorously integrate something like SElinux they throw layers over layers of half-backed "sandboxes", up to the point to separate applications with Xen (Qube-os), then you find out about Meltdown, and we are back in 1990.

Pledge is a bad example, it isn't applied to a lot of packages in the ports tree and it's infeasible to do it for every program. In the end you'll find you end up with the same situation as Linux: another layer on top with daemons implementing blanket security policies using pledge on behalf of the programs. Kind of like... a sandbox.

SELinux is also a bad example, even if you decide you're using that as the underlying technology you still need to implement a sandbox with various on top of it. SELinux does nothing without those rules.

>SELinux is also a bad example

No why? If you have the right (and correct) rules, SELinux absolutely act's as a "sandbox", that's exactly what i meant, a sandbox don't need's to be another layer of software. Run in your "namespace", can just create/access/execute/read your port, files, memory..that's it, that's a sandboxed application.

For example that "namespace-sandbox" is standard in Plan9/9front...without any additional software, just the filesystem and 9p.

https://dwalsh.fedorapeople.org/SELinux/Presentations/sandbo...

Yeah but I mean you still have to set up the sandbox rules and maintain them and the tools if you want a user-friendly sandbox or a nice GUI to manage it.

>For example that "namespace-sandbox" is standard in Plan9/9front...without any additional software, just the filesystem and 9p.

This is what I mean, Plan9 style mount namespaces are also available in Linux and are preferable to SELinux for containers and sandboxes because they're actually simpler and less trouble.

>and are preferable to SELinux for containers and sandboxes because they're actually simpler and less trouble

Hell YES...high five!! ;)

OpenBSD's pledge and unveil are intrinsic while Linux crappy sandbox it's extrinsic...

Just imagine getting pwned by malware bundled in a calculator...

What is the connection here? Why would you install the calculator not coming from your distribution?

Because there is a push for software developers to be able to package directly for end users. Without devolving into the usual flame war of whether it's a good idea or not, once you install any piece of software you incur some security risks. It's not like distro maintainers are a 100% guarantee there won't be a backdoor in the binary, and compiling software from source doesn't free you from risks either, unless you code-review everything you install.

My point is, containerisation on Linux isn't necessarily slow—in fact it's unnoticeable if implemented correctly—and I prefer to default to having a decent amount of security by containerising as much software as I can, whatever the origin. Including, and especially software like the calculator, since it should not be able to do anything more than show a GUI and add numbers together.

That's not what i asked, why do you trust a no name dev more then the distro your kernel is coming from? And do you really think flatpack prevents you from running packed malware?

Why do you assume the flatpak comes from a no name dev? My calculator flatpak comes from the same people who wrote it, and I obviously trust them, otherwise I wouldn't be using their application.

So why should I trust them less than my distribution?

Ever used npm?

No, and how is that even relevant?

>So why should I trust them less than my distribution?

Just use google -> npm malware

I said I'm not using npm.

With my calculator flatpak I only have to trust one person and to a much lesser degree, because they declared that the calculator can't access my personal files to begin with. The same app in my distribution repository has full read-write access to all my users files, network access and much more. So yeah, I trust it more.

Distribution maintainers are nothing but a middle man, which don't even audit the code they package, so there's nothing I gain from them.

In my particular case: I don't want to wait months or even years for updates to arrive in my distribution. With the Flatpak version I get updates usually on the same day they are published, since the Flatpak is also maintained by the calculator developers, and I also get a calculator which can't access my ssh keys or the internet, due to sandboxing. And in case of any breakage, I can also quickly roll back to the last version.

Without flatpak I'd need to use some rolling release distribution, where not just a few applications get updated quickly, but also the rest of the system, which I'm not interested in.

username checks out ;)