News for hackers. Stuff that matters.
Re:Flatpak – a security nightmare – 2 years later (2020) by alerighi on Sunday March 21, 2021 @07:03AM (#26529569)
Is not that simple. First you would need a flatpack daemon that manages that permission, that the application could ask for a path (e.g. by writing in a control socket) and the daemon asks the user and mounts that paths inside the container, and then inform the application that the operation is successful. But that would require modifying the application, and not in a trivial way, and it's unacceptable (you need to fork basically every application that you package for flatpack, and the filesystem access could be in various places).

A more acceptable solution would be to intercept all the filesystem related system calls, look if a path is accessible, and if not ask for the permission and either try again the system call and return the result or return to the application E_AGAIN (but is not ideal since not a lot of applications handle that correctly). But this approach would probably require a kernel module, or you can do that with eBPF but obviously you would need CAP_SYS_ADMIN capability so not really possible.

The approach of flatpack is create a container with all the paths that you know the application can access and then jump into the container. A simple solution that even doesn't require a daemon and doesn't require modifying the applications.

Re:Flatpak – a security nightmare – 2 years later (2020) by ddtaylor on Sunday March 21, 2021 @07:39AM (#26529687)
> But that would require modifying the application

Technically it can be done using LD_PRELOAD on fopen() and such.

Re:Flatpak – a security nightmare – 2 years later (2020) by maffydub on Sunday March 21, 2021 @07:42AM (#26529696)
Can it?

If my application invokes syscalls directly, that wouldn't hit anything interposed using LD_PRELOAD.

Re:Flatpak – a security nightmare – 2 years later (2020) by acka on Sunday March 21, 2021 @08:11AM (#26529836)
Firejail[1] is IMO a good alternative. It handles sandboxing using Linux namespaces and seccomp-bpf.

[1] https://firejail.wordpress.com/

Re:Flatpak – a security nightmare – 2 years later (2020) by ddtaylor on Sunday March 21, 2021 @07:59AM (#26529767)
It will certainly work for the vast majority that are using #include <stdio.h> and more importantly for the various GUI apps that are using GTK/Qt dialogs.
Re:Flatpak – a security nightmare – 2 years later (2020) by maffydub on Monday March 22, 2021 @04:29AM (#26538132)
This is for security, though - you can't just assume it's good enough because it will work for most benign applications - you need to be sure it will work for all applications - benign or malicious!

There are other solutions such as seccomp (as siblings of your post have pointed out) that solve this securely, but LD_PRELOAD won't.

Re:Flatpak – a security nightmare – 2 years later (2020) by cycloptic on Sunday March 21, 2021 @08:02AM (#26529779)
The safest way to do it would be to implement it with seccomp so you unconditionally block those syscalls.