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

71–80 of 296 posts

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

#71

Post by higerordermap »

gspr wrote: post #28
kelnos wrote: post #16

Earlier quoted context omitted.

I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…

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.

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

#72

Post by eeZah7Ux »

josefx wrote: post #15
nodja wrote: post #4

All of the examples are apps where the main use is manipulating files on the system. Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?

> All of the examples are apps where the main use is manipulating files on the system. So do users, still can't overwrite system wide settings without first getting root. Decent sand boxing has to be granular enough to cover partial access. Of course the hard part on Linux would be locking access to files like ~/.bashrc without completely blocking access to the home directory, that probably would require an exhaustiv…

You described what firejail is already doing.

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

#73

Post by Groxx »

foobar33333 wrote: post #30
ekianjo wrote: post #12

Earlier quoted context omitted.

note that the response partially agrees with the points raised, it looks like a constructive discussion overall.

The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now" If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets e…

So the tradeoff is "weak sandboxing, or up-to-date security patches".

TBH I don't know which I prefer. But I suspect the lack of security patches will continue to get worse and worse as time goes on.

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

#74

Post by Iolaum »

alpaca128 wrote: post #42
kelnos wrote: post #16

Earlier quoted context omitted.

I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…

From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying. I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to cop…

You can use flatseal[0] to allow apps access to extra folders in the filesystem. It's a GUI app that makes it much easier than learning how to do the same thing from the command line.

[0]: https://flathub.org/apps/details/com.github.tchx84.Flatseal

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

#75

Post by brnt »

alpaca128 wrote: post #42
kelnos wrote: post #16

Earlier quoted context omitted.

I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…

From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying. I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to cop…

Took me a while to figure out that Signal can't save outside of Downloads as well, especially since its not the default dir it opens when trying to save an file. There's no feedback of any kind.

I see flatpak more as a distro independent package format than a way to secure my system.

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

#76

Post by necovek »

nextlevelwizard wrote: post #17
ekianjo wrote: post #12

Earlier quoted context omitted.

note that the response partially agrees with the points raised, it looks like a constructive discussion overall.

It is hard to guess at motives when author is unknown. Or when neither of the CVE links go anywhere. Maybe I've understood how Flatpaks work incorrectly (please correct me if so), but the applications are ran in containers. So how would an attacker exploit CVE-2019-17498 on a Gitg? Its not like Gitg has a port open for listening incoming messages. With ffmpeg I don't know if things like Chromium are actually using th…

You've misunderstood "how Flatpaks work": they are using the same system calls that containers use for containerization but in a different way, look at https://en.wikipedia.org/wiki/Linux_namespaces (Snaps use AppArmor too if that's a more familiar technology).

They are not containers in themselves: if you feel this is pedantic, the way namespaces are used can make all the difference (eg. why you should not be running stuff in docker containers as root which can easily be used to get root on the host).

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

#77

Post by necovek »

akvadrako wrote: post #38
littlestymaar wrote: post #21

Earlier quoted context omitted.

Look at how the Web standbox is designed: of course some websites must access to your camera (Zoom, Jitsi, MS Teams, etc.) yet you still have to give them the permission! And it's a fine-grained permission (don't want to share your microphone, Ok just don't). I want to be able to give programs exactly access to I want it to access, and just when I want to give it that access. This way I'm sure my SSH keys (or private…

You can control the permissions with flatpak, it just doesn't ask you about each one by default. But if that's what you're asking for it isn't a major change. It could even be done by using a simple shell script for installation.

On-installation is hugely different from on-use.

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

#78

Post by mrweasel »

Security updates are a huge issue for most “container” formats. Even official image on Docker Hub receive almost zero security updates and most companies seem to have no policy on how to keep container, be it Flatpak, Docker or even LXC containers updated.

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

#79

Post by mewse »

tim333 wrote: post #19
santoshalper wrote: post #11

Earlier quoted context omitted.

It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.

I'd be fairly happy for an IDE to stick to the /dev folder where I have that kind of stuff.

Yeah, my development practice also principally centers around having clang repeatedly compile /dev/urandom until it produces a program that does what I wanted.

My colleagues sometimes complain that it takes somewhat longer to do it this way than the old-fashioned “writing the code yourself” way, but on the plus side I don’t have to actually be present at all while it’s doing it. Just have it send you an email once the unit tests all pass and you’re good! This development approach has given me a bunch more time to train my monkeys to type Shakespeare. They’re getting pretty good at MacBeth, and I’m hoping to move on to Othello next week.

A friend of mine questioned why I involve ‘clang’ in the process at all; why not just echo /dev/urandom into a file, set it as executable, and then run it, instead of mucking around with the whole “compiling it with clang” step, but I pointed out, you know, at that point is it even really programming any more?

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

#80

Post by foobar33333 »

eeZah7Ux wrote: post #63
foobar33333 wrote: post #30

Earlier quoted context omitted.

The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now" If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets e…

> If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo True, and the same is true for flatpak given that the author of the package controls the sandboxing. The only solution is to have 1 or 2 trusted packagers to review the package, including its code - which is what some Linux distributions do. Furthermore, Debian does a long release freez…

Flathub actually does review submissions reasonably well. You have to give a justification for each permission you request and why it couldn't be done in any other way.
Post reply on HN