Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak – a security nightmare – 2 years later (2020)

flatkill.org

Post reply on HN
Print view View original

151–160 of 296 posts

Re: Flatpak – a security nightmare – 2 years later (2020)

#151

Post by fragileone »

foobar33333 wrote: post #29
dastx wrote: post #24

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when promp…

I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it. The current strategy seems to be having outsiders packaging all the desktop software in t…

Agreed, the current state is such that many developers either rely on package managers for auto-updates (thus lacks sandboxing anyway) or use Snap (which is usually similarly not sandboxed and you have to put your trust in some proprietary cloud platform to push code to your computer). Just getting devs to support Flatpak is an effort, but once that's done sandboxing can be worked on later.

Re: Flatpak – a security nightmare – 2 years later (2020)

#152

Post by pjmlp »

KronisLV wrote: post #56
fulafel wrote: post #36

Earlier quoted context omitted.

This is probably quite hard to implement without modifying the packaged applications. Needs something like a mechanism of pausing, instead of denying, a system call in the kernel and calling back to userspace, which would then load new policy into the ruleset on the fly and resume execution. Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the p…

Doesn't this imply that Linux is falling behind somewhat in the area of permissions management? Personally, i think that limiting access to files and such based on users and groups simply isn't enough and instead the user should be prompted (or should be able to configure) which piece of software is allowed to do what (network access, file system access, talking to specific devices) based on their own individual need…

Android only uses the Linux kernel, everything else is completly unrelated to GNU/Linux, besides the lockdown enforced via LinuxSE and seccomp, so Google could naturally make this kind of customization.

Re: Flatpak – a security nightmare – 2 years later (2020)

#154

Post by pjfin123 »

I don't have anything against Flatpak but maintain a Snap package and think Snap has made a lot of good design decisions even if it still has rough edges. For a basic application it's pretty easy to package for Snap. A lot of the things that bother Linux power users like polluting their mounted file systems wouldn't matter to regular users. My understanding is they support either pre-declaring permissions or requesting them at run time.

https://github.com/argosopentech/argos-translate

Re: Flatpak – a security nightmare – 2 years later (2020)

#155

Post by pjmlp »

my123 wrote: post #141
syockit wrote: post #135

Earlier quoted context omitted.

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

For Windows, there are the Win32 apps that you talk about, which aren't sandboxed. And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.

Win32 applications can also be sandboxed, when packaged as MSIX.

Windows 10X original roadmap was to merge both sandbox models, and it is also part of Project Reunion goals.

Re: Flatpak – a security nightmare – 2 years later (2020)

#156

Post by XorNot »

Daho0n wrote: post #139
XorNot wrote: post #127

Earlier quoted context omitted.

This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating…

Why do you want a new language for this?

Because what we need to be expressing - and it would be better at a language level however that's done: is something that can be introspected reliably by the OS at runtime to create assurances about how data is used in the system.

We shouldn't need to put data in and then trust it doesn't somehow wind up being sent over the internet - we should be able to prove this before we put it in.

The system needed is something like SELinux for programs - data goes in and gets tagged that it's there, and before we do that whatever the trusted OS is prompting us for permissions for, it's actually proving the application will do.

Obviously this might not be a new language: abstracting out how files are used so applications go through trusted interfaces to do things is probably the better solution but the key is starting at user data first and being able to make positive assertions about what can't happen (in the absence of bugs in the enforcement mechanism obviously): i.e. "these personal photos can only be viewed by me, and be sent encrypted over the network to these classes of recipient encryption key" should be a reasonable policy statement we can enforce without needing to explicitly grant permissions to every app which wants to do something with photos.

If we can prove at runtime the app can't or won't be able violate policy, then we don't need to keep throwing "do you want to allow?" dialogs in the user's face and pretend we've done something useful for their security.

To my mind this ultimately requires us to have a runtime framework for tracking data provenance and entropy for what we feed into the system: at any given time we want the OS to have a good idea of where any set of data in an application came from, and how much entropy has been increased by transforms against it (i.e. taking the length of a file doesn't leak much data about it, but letting that be an unmitigated side-channel would be worse).

For example: the operation the user doesn't need to see is "this application is syncing your photos to your Google account". The operation they should be prompted for is "this application dumped a whole lot of data into a function we don't recognize, and the output data which we can see is tagged as possibly containing your photos, it now wants to send to this unknown IP address".

Re: Flatpak – a security nightmare – 2 years later (2020)

#157

Post by benibela »

higerordermap wrote: post #71
gspr wrote: post #28

Earlier quoted context omitted.

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.

I have run the browser on a separate user account for years

Re: Flatpak – a security nightmare – 2 years later (2020)

#158

Post by pjmlp »

Shadonototro wrote: post #115

it doesn't matter what people think both snap/flap user experience is trash linux desktop is doomed to fail people the people who make decisions are clueless and tasteless

The Linux Desktop has failed already thanks to the endless fragmentation and religious attacks on drivers.

Even ChromeOS and Android only package the Linux kernel, while building their own userspace on top.

With the Web turning into ChromeOS, and the return of timesharing via the cloud, there is even less reasons to care about the GNU/Linux desktop.

Re: Flatpak – a security nightmare – 2 years later (2020)

#159

Post by thu2111 »

XorNot wrote: post #127
varispeed wrote: post #123

Earlier quoted context omitted.

In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it? I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a p…

This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating…

That can already be implemented with sufficiently creative uses of the JVM sandboxing tech.

Re: Flatpak – a security nightmare – 2 years later (2020)

#160

Post by gspr »

higerordermap wrote: post #71
gspr wrote: post #28

Earlier quoted context omitted.

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.

> We know some things are objectively better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake.

Absolutely. That's why the comment that makes you characterize me as a luddite explicitly referred to the "sandbox everything wave".

Sandboxing has its place. Sandboxing everything (i.e. the "Flatpak way") is what I'm commenting on.

Post reply on HN