Live data from Hacker News

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

flatkill.org

191–200 of 296 posts

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

#191

Earlier quoted context omitted.

Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.

And then have a barrage of users complaining that their app packaged in flatpak doesn't work.

Perhaps make it an optional setting?

"Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.

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

#193
Semi-related. I wanted to run Amarok 1.4 recently (because I had been having a discussion about how no music player on Linux touches MusicBee, and the last one that had promise, before the developers lost their minds, was Amarok 1.4 - yes I know about Clementine etc but MusicBee still wipes the floor with all of them. This is a digression).

Anyway, I spent about an hour attempting to get get it to run on my up-to-date Mint laptop. Now, Amarok 1.4 is 12 years old, so if you want to get it to run, you'll either have to compile it (which means getting your hands on the 12 year old KDE libs), run a 12 year old Linux distribution in a VM, or... Dockerize it. Now you see where the flatpak connection comes in.

Step 1: Find an Ubuntu 8.10 ISO and mounted it:

sudo mount -o loop ubuntu-8.10-desktop-amd64.iso /mnt/intrepid

Step 2: Unqsquash the filesystem:

sudo apt-get install -y squashfs-tools sudo unsquashfs -f -d /tmp/unsquashfs /mnt/intrepid/casper/filesystem.squashfs

Step 3: Import the tarball into a Docker image:

sudo tar -C /tmp/unsquashfs -c . | docker import - ubuntu/intrepid

Step 4: Run interactively and install Amarok:

docker run -it --entrypoint=/bin/bash ubuntu/intrepid

(NOTE: At this point, it was pretty hard to find an apt repo for Ubuntu 8.10 but, amazingly, one or two still exist online. So I edited the apt sources, ran apt-get update && apt-get install -y amarok. I also created a user to run Amarok - one whose uid/gid matched my own user. These commands are left as an exercise for the reader)

So I dockerized Amazok 1.4.10 / Ubuntu 8.10. What next? Well, I could have created a Dockerfile that started "FROM ubuntu/intrepid" and repeated all of my manual work I did in the interactive container, but I'm not keeping this thing, so I just did this the hacky way:

docker export quirky_mendel -o ubuntu_intrepid_amarok.tar

docker import intrepid_amarok.tar amarok:1.4.10

Now I have a docker image called "amarok:1.4.10" which I can share on Docker Hub! Does it work?

docker run -it --entrypoint=/usr/bin/amarok --rm --name amarok --net=host --user amarok --privileged -e DISPLAY=:0 -v ${HOME}/.Xauthority:/home/amarok/.Xauthority amarok:1.4.10

IT WORKS! A 12 year old music player running in a docker container on the latest Linux Mint. My alternative to Flatpak / Snap etc. Is it safe? Nope! It's running in an Ubuntu image that wasn't updated since 2008.

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

#194

Earlier quoted context omitted.

And then have a barrage of users complaining that their app packaged in flatpak doesn't work.

Perhaps make it an optional setting? "Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.

It is... you can add/remove any paths you like. The default errs into what users are used to.

See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.

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

#195
Containers on the desktop are a symptom of a festering underlying disease. They are not the cure for anything. Modern linux development is extremely rapid pace and is 100% targeted at the needs of the corporate entities paying for the development. This extremely fast pace of change in the kernel and underlying libs, langs, and compilers means that a desktop environment put together 4 years ago cannot realistically compile or run software written today.

That's okay for mega-corps who re-build the entire software universe every time they want to make a change. Or for those who ignore desktop entirely and just "deploy" containers.

And that's lead us to today. Linux desktop can't live for more than a few years on it's own. In order to deal with the backwards incompatible features some desktop distros have shifted to using containers. But this doesn't fix the futureshock. It only makes things for desktop users worse.

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

#196

Hot take: Per-application sandboxing is (in general) fundamentally flawed idea, as applications are just tools to manipulate data, while data needs to be protected from unintended manipulations, but such protection should not encumber intended manipulations. What manipulation is intended depends on worflow, not application. Such setup can work on phones due to their limited use cases, but not on desktop. What we need…

The world doesn't work like that.

1) application sandboxing isolates different vendor's code, some of which may be security / privacy infringing.

2) There wouldn't be a problem with data sharing in a properly designed sandboxing system. There will be shared filesystem, file chooser / save dialogues so that's not really a problem.

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

#197
post #178

Earlier quoted context omitted.

Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc."). Suddenly, it's now on app developer to support the packaging system and not the other way around.

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.

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

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

#198
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.

So you think that disallowing access to word processor files to zip and unzip, or backup utilities, or ... is a perfectly reasonable way of doing things?

Because that's what we do on the web. Every app only has access to it's own files and 10 or so standard clipboard formats (and ONLY through the clipboard).

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

#200

Containers on the desktop are a symptom of a festering underlying disease. They are not the cure for anything. Modern linux development is extremely rapid pace and is 100% targeted at the needs of the corporate entities paying for the development. This extremely fast pace of change in the kernel and underlying libs, langs, and compilers means that a desktop environment put together 4 years ago cannot realistically co…

I only use Flatpak apps when it's my only option and the only places that seems to be are Electron apps.

Discord & Slack, I'm looking at you.

I also run a rolling-release distribution...

Post reply on HN