Conversation

Replying to

and

I'm assuming if you pass a file descriptor into the sandbox from outside it, you're okay with it being accessed. If you don't want that, don't do it.

Replying to

and

Look at this small fraction of what they're building: flatpak.github.io/xdg-desktop-po This doesn't include a whole lot of the baseline IPC. It's going to get 100x larger and far more complicated as they fill out the capabilities to actually be able to sandbox more complex real apps.

Replying to

and

This is all stuff that simply should not exist.

Replying to

and

So how does an application do something like using OpenGL, opening a file with user consent, taking a picture with user consent, obtaining access to take multiple pictures within the current session (or persistently, for a camera app), and so on and so on?

Replying to

and

I have never once wanted a desktop app to "take a picture". If I want to take a picture with my webcam I'll do it with a native utility I trust then open the file. This is a general principle: vetted native apps for privileged things, 3p junk in a HARD sandbox.

Replying to

and

But of course this is a replay of the FDO folks trying to recreate all the mistakes of Windows on the Linux Desktop, only this time it's recreating all the mistakes of Android... 🤦🤦🤦

Replying to

and

They're trying to copy the way it works on Android although often based on how things worked in Android 4.4.x to 6.x rather than how they work now. That's just what they're trying to do and isn't really how things work. The way it usually works is apps opt-out of the sandboxing.

Replying to

and

"Opt out of the sandboxing" is accepting the narrative that "self-contained applications" and "sandboxing" are the same problem domain. If you reject that, it's not a problem except in a ux sense (you need to manually bind-mount the files you want to access into the ns).

Replying to

and

AppImage sticks to just providing self-contained applications and has existed for a long time. Most of the point and the work on Flatpak seems to be bringing application sandboxing. Packaging up applications is part of it but more of an afterthought and secondary thing for them.

Replying to

and

Another *nasty* problem facing Flatpak is that it has to support systems with SELinux not in use. It can’t rely on SELinux because not every distro supports SELinux. And Flatpak apps are usually native apps, unlike Android where everything uses abstracted APIs.

Replying to

and

SELinux is an implementation detail on Android from app perspective and could be something else. There's a lot of value in declarative, static security policies. Linux kernel has decided LSMs and eBPF obsolete doing things other ways so that's another major reason for it.

3:54 AM · Oct 19, 2021Twitter Web App

Replying to

and

Android used to have gid-based socket restrictions similar to the grsecurity patches and a network usage monitoring kernel module, etc. All that stuff has been removed since it supports mainline kernels. Instead netd (but nothing else) can use a bpfloader program to use eBPF.

Replying to

and

Just the direction things are headed for Linux. They had to replace a 40 line of code kernel patch and a 500 line of code kernel module with thousands of lines of userspace management code and thousands of lines of eBPF management and compilation stuff. I don't find it cleaner.

Show replies

Replying to

and

Does that mean Flatpak should require SELinux to be enforcing to be used?

Replying to

and

They could extend Landlock to cover things that are only possible via SELinux and could create a static policy format for it since it's really not great to need to write programs to restrict what programs can do rather than at least mostly declarative policies.