Hacker News Reader

Comment by bandrami | Hacker News Reader

Flatpak is a non-starter for me. The runtimes required by my office would mean 2 KDE versions and 2 Gnome versions installed as flatpak runtimes in addition to the KDE running on the host, which quintuples the security space I need to monitor.

Sweeping package management problems under a rug doesn't actually make them go away.

View on HN

What do you mean by "monitoring security spaces"? Are you frequently refreshing the bug boards of every library your applications and OS uses?

Not all. But I'd wager it's not uncommon for a lot of linux people to periodically check their most used software with the largest attack surfaces. Browsers, document viewers/editors, mail clients, decompressors etc.

We do not :)

I would definitely like to say I do but I definitely do not.

I mean, I don't do it for my home computer, but I do it for the fleet of computers I manage at work because someone gives me money to do that.

I'm very interested in some sort of daemon that regularly scans for vulnerable binaries/libraries and produces desktop notifications about this and/or hosts a web interface to review issues. I do use clamav for malicious files, but bug advisories/vulnerabilities are another area I wish I could make convenient to monitor for personal computing. I've seen things like Splunk reports in enterprise settings, but not for personal 'digital hygiene'

Anybody have a list of open source solutions here?

This sounds like a fit for NESSUS

Every SIEM does something like that, but somebody has to actually look at the screen and take actions based on it, and that's what my job is.

No, I trust my distribution to do that for me, and more importantly update libraries as needed. With snap and flatpack I have to trust every single upstream to keep track as if there is a problem i'm vulnerable until everyone updates.

I'm a sysadmin, and that's a big part of the job, yes.

Flatpaks unlike Snaps are actually sandboxed properly.

Just being sandboxed though isn't a help if you actively want the software to process sensitive data! If you want to read a private document in LibreOffice, you have to be sure your copy of LibreOffice and every library it calls is trustworthy and reasonably secure.

I dunno, if it's sandboxed and doesn't have network access then the only attacks I can think of are either really indirect (embedding an attack in saved files in hopes of hitting another user) or really targeted (altering a specific document or phrase when it's read). Assuming the sandbox works and includes blocking of network access, what attack do you see a word processor performing even when handed sensitive data?

Most word processors have some web abilities. Click and link and the web browser opens. That link can be custom crafted to send data.

Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server.

This has a level of indirection, but that just delays things until the next login. With a little more work there are infinite other places you could inject that might run sooner.

> Suppose your word processor is allowed to write to arbitrary files in your home directory. It writes a line into your .profile that CURLs your sensitive data to it's server.

Yeah, that's like the poster child of sandboxing; I am very much supposing that my word processor is not allowed to touch arbitrary files.

You're ignoring the supply chain side.

RHEL RPMs are signed by Red Hat. Flatpaks are signed by... whoever happens to maintain that flatpak.

Er, yes? I am ignoring the supply chain, because I'm commenting on the sandboxing, which is separate from who's publishing the software. (The only connection I see is that whoever publishes the flatpak is responsible for setting the default sandboxing config, which is important but I don't know how else you'd do it. But then RPMs aren't sandboxed at all, so what does it matter who signs it? We're talking about sandboxing here.)

I dont care about sandboxing though; the valuable data is what the apps themselves are handling so it doesn't help.

But at any rate the multiple runtimes with multiple upstreams are why it's a non-starter from a security PoV; the uselessness of sandboxing is more just icing.

I literally don't care about sandboxing. The data the apps themselves handle is the only thing valuable; protecting the rest of the system is pointless since I can reimage essentially for free at any point.

If malicious software takes over my browser it can steal my identity, wreck my finances, and ruin all my business and personal relationships. The fact that it can't add a printer is interesting but not really at the same level of concern.

I'm using separate browsers in separate VMs for banking, business and personal things. And it's all with a great UX on Qubes OS.

Full or no filesystem access is very, very far from proper sandboxing.

As far as I know, Flatpak offers a fair amount of control over sandboxing. It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your system. The alternative might be giving it access to one particular directories, and then copying files there when you want to work on them. But that's already pretty cumbersome, something only the paranoid would bother with.

Realistically, I know that I do not have the skills to evaluate complicated applications and their complicated dependencies for security characteristics, so I am 100% reliant on packagers, maintainers, etc. for my security anyway. I'd rather just donate to the people publishing and maintaining the packages and hope that they are doing the job well, than fruitlessly attempt to fuss over it myself.

> It's just that isn't particularly useful for some thing like a document processing application that you usually want to be able to use on files in various parts of your syste

The good news is there is a solution to this. The trusted system shows a file picker, and then grants access to the sandboxes application.

This is called the File Chooser Portal. https://docs.flatpak.org/en/latest/portal-api-reference.html...

I didn't realize this existed, it seems a lot like what Apple is doing for the photo gallery in recent iOS versions. That's a nice extra safety feature.

I suppose additional security features inspired by mobile systems couldn't hurt either. Like a pop-up whenever something accesses the clipboard.

Yup, mobile is ahead of desktop here, in terms of making it reasonably safe to run moderately questionable applications.

I just hope flatpak sandboxing works well...

That's roughly what our workflow does (DFARS requires it or something like it for CUI) and this story annoys me because the entire selling point of RHEL (which is what we use) is that you aren't having to audit a bunch of random upstreams because they do it for you. It's why their going all-in on flatpak was such a surprise to a lot of us.

That's fair. Maybe some large organization will be willing to sponsor their maintenance of RPMs, or of the Flatpaks directly. After spending hours trying to package even simple programs in RPM and DEB, I am very sympathetic to the idea that one cross-OS packaging format is enough. Why shouldn't there be "enterprise audited Flatpak" like anything else?

That's actually a really cool idea and I'll make sure to credit nerdponx for it if I succeed.

Sandboxing is also an orthogonal question from packaging. OpenBSD sandboxes applications using pledge; it doesn't require maintaining multiple parallel runtimes to do it.

Yes but pledge works at the source level. It's the job of the developer to set the correct pledge calls.

Not sure which package problems are swept away according to you? You mean possible issues with library reuse, devendoring, etc?

Besides, why 2 KDE AND 2 Gnome versions would be needed. The 'minimal' freedesktop would most likely suffice.

Do you use flatpaks? Each application brings with it a desktop runtime (Gnome or KDE or sometimes just the FDo that underlies Gnome and KDE), and each of those desktop runtimes is versioned. The problem is these don't get updated on Flathub at the same time, so the vector art editor brings one version of Gnome and the IDE brings a different version of Gnome.

Now, it's possible to build my own flatpaks and keep everything updated, but if I'm doing that I might as well just build the actual software and use the distro's package management system.

Reply on news.ycombinator.com