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

Re:Flatpak – a security nightmare – 2 years later (2020) by Spivak on Sunday March 21, 2021 @10:03AM (#26530518)

I mean what do you want to have happen? ptrace every application, stop on every openAt(2) call and pop up a permissions dialog?

macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.

[ Parent | on HN ]

Re:Flatpak – a security nightmare – 2 years later (2020) by GekkePrutser on Sunday March 21, 2021 @02:29PM (#26532654)

And also because macOS has only one desktop environment :)

[ Parent | on HN ]

Re:Flatpak – a security nightmare – 2 years later (2020) by orra on Sunday March 21, 2021 @11:36AM (#26531203)

TBF you could put support into the two common GUI toolkits, to defer to a Flatpak portal.

[ Parent | on HN ]

Re:Flatpak – a security nightmare – 2 years later (2020) by Spivak on Sunday March 21, 2021 @11:54AM (#26531327)

But that’s exactly what GTK and QT have! It’s what to do with apps that don’t use some abstraction that supports portals that’s the issue.

[ Parent | on HN ]

Re:Flatpak – a security nightmare – 2 years later (2020) by orra on Sunday March 21, 2021 @02:40PM (#26532746)

Well, there’ll always be a long tail. But if you start with the popular apps and frameworks first, you get the most bang for your buck.

It wouldn't surprise me however if sandboxing is only a good model for GUI not console app.

IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.

[ Parent | on HN ]

Re:Flatpak – a security nightmare – 2 years later (2020) by AshamedCaptain on Monday March 22, 2021 @11:45AM (#26542436)

As mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.

[ Parent | on HN ]