Skip to main content

Anyone in my network interested in research and prototype network portal for Flatpak?

In the long run we are interested in:

• Give more control to users over app network access
• Allow apps that need network access to be considered “Safe”

We expect something like unsharing the network namespace and a bridge on the host for permissions / monitoring.

Boost welcome :boost_love:

1/2 🧵

#FediHire #Flatpak #Flathub #Linux #Snap #containers #Docker #freedesktop #Ubuntu #Fedora

#linux #Flatpak #docker #ubuntu #fedora #flathub #snap #FediHire #freedesktop #containers
This entry was edited (1 month ago)

Federico Mena Quintero reshared this.

in reply to Sonny

Sonny
Sonny
• •

Requirements

• System programming (C)
• relevant network technologies
• ideally Linux container technologies
• Good communication skills

It would be a contracting gig, and you'll be joining a great team:

https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/

Send resume/portfolio to stf@gnome.org

2/2 🧵

GNOME Recognized as Public Interest Infrastructure – The GNOME Foundation

foundation.gnome.org
This entry was edited (1 month ago)

Federico Mena Quintero reshared this.

in reply to Astro

Sonny
Sonny
• •

Flatpak, bubblewrap and the portals are written in C.

I'm not against writing the prototype in Rust but being comfortable with C is a requirement for the project.

This entry was edited (1 month ago)
in reply to Sonny

Gary "grim" Kramlich
Gary "grim" Kramlich
• •
is this going to cover any traversal stuff too? We have a library we started for this but haven't gotten too far with as we have a lot to do ahead of it. But we also need to know things like all ip addresses for the machine and remote addresses too.
in reply to Gary "grim" Kramlich

Sonny
Sonny
• •

@grimmy

Are you asking if the bridge would take care of NAT traversal for apps?

That's an interesting idea, but it's not in scope for now.

@Gary "grim" Kramlich
in reply to Sonny

Gary "grim" Kramlich
Gary "grim" Kramlich
• •
Yeah asking that and like what else with the bridge entail. In other words, is it even possible for Pidgin to get marked as safe as we need to be able to connect to any/all network, plus peers, etc. :)
in reply to Gary "grim" Kramlich

Sonny
Sonny
• •
Sorry I don't know yet 😅
This entry was edited (1 month ago)
in reply to Sonny

Neal Gompa (ニール・ゴンパ) :fedora:
Neal Gompa (ニール・ゴンパ) :fedora:
• •
I'm a little confused what you mean by "control [...] over app network access"? What is the expectation of a granular network access permission?
in reply to Sonny

James Milne
James Milne
• •
I'd love to be able to run Wireshark properly from a Flatpak, but if it's completely isolated from all the other traffic on the machine that would be a bit useless....
in reply to Sonny

Astro
Astro
• •
A bridge is very dependent on host config. Maybe this can be done with eBPF as well.
in reply to Astro

Sonny
Sonny
• •
@astro I don't know too much about eBPF but in general it's smart for us poor desktop enthusiasts to bet on technologies used by big tech in the server/cloud space 👍
@Astro
in reply to Sonny

Kai Lu:ke
Kai Lu:ke
• •
@astro With bpf cgroup socket egress/ingress filters one can have fine-grained firewall rules. A PoC filter would just do "on/off", and then advance into protocol, port, address filtering (HTTP parsing is not really needed). Interesting would be a portal design that works with unmodified apps by detecting packet drops due to initial policy, and then open a dialog to let a ingress/egress connection through (but the app could also ask upfront (fine/coarse-grained).
@Astro
in reply to Sonny

Petr Menšík :fedora:
Petr Menšík :fedora:
• •
I were thinking about at least alternative DNS servers offered to untrusted apps would be great. It might allow only selected domains access or monitoring what they actually use. I think it is difficult to monitor queries from each app today. Should be made easier. But just idea, I do not have time to work on it in near future.
in reply to Sonny

Will Thompson
Will Thompson
• •
I feel the need to say that I think dubbing needing network access (a thing that most apps need and have no alternative to) "probably safe" in the first place is a mistake that could be easily resolved without any meaningful reduction in user security by just not considering network access in the safety tile.
in reply to Will Thompson

Sonny
Sonny
• •

@wjt

I disagree

• network can be used to talk to services on the host
• network is the only thing needed to scam people, see recent Snap crypto scam events
• some network usage are illegal in certain regions (ex bittorrent)

But more importantly, if we mark it as safe now, that's it, we lose the leverage to ever get something better than broad and uncontrolled network access or encourage apps to work offline first.

@Will Thompson
in reply to Sonny

Valentin David
Valentin David
• •
@wjt where is BitTorrent illegal?
@Will Thompson
in reply to Valentin David

Sonny
Sonny
• •

@Valentin @wjt

I was referring to torrenting (uploading) copyrighted material. And the fact that you can receive a fine after having used an app.

It might not be clear to users that's what an app is doing, see Popcorn Time.

@Valentin David @Will Thompson
in reply to Sonny

Will Thompson
Will Thompson
• •
Real cryptocurrency apps need at least as much network access as scam ones. Why would telling a user that what they think is a real cryptocurrency app needs to connect to the internet help them to detect that it will scam them?
in reply to Will Thompson

Sonny
Sonny
• •

@wjt

I can imagine something like a dialog

"Crypto wallet wants to communicate with xfever4ever.xz" yes/no

We can put some educational info in the dialog. We can put a big red flag warning if the domain is on a malware list etc

@Will Thompson
in reply to Sonny

Sonny
Sonny
• •
@wjt the portal could also be used for parental control where privacy/security requirement is a whole other paradigm
@Will Thompson
in reply to Sonny

Will Thompson
Will Thompson
• •

I think you are overestimating how much interest most people have in reading a domain name and guessing whether it is safe in order to use an app, rather than clicking through; and the ability of any human to determine whether e.g. d1anzknqnc1kmb.cloudfront.net is a safe domain to talk to. (That's the CDN that served Endless OS images for many years.)

It's an interesting R&D project but I would really like to see some user research on the intended flows to go with it.

in reply to Will Thompson

Sonny
Sonny
• •

@wjt research is part of the project

Note that Chrome and Firefox do exactly that with malware domain.

@Will Thompson
in reply to Sonny

popey
popey
• •
@wjt FWIW the big one (as a snap) first made a connection to a completely legitimate currency api before it did the nefarious stuff. Plus, the later ones were just web wrappers so the actual connections to dodgy places (beyond the host of html and css) came from the web host.
@Will Thompson
in reply to popey

Sonny
Sonny
• •

@popey @wjt

Good to know 👍

I don't want to focus too much on that case in the conversation.

It's a solved one for us by acknowledging that completely unrestricted network access is unsafe and doing manual reviews.

The way forward is how to consider apps with network needs as safe. Building a portal/API will bring a reasonable compromise.

As always, we'll make sure to share whatever we come up with.

@popey @Will Thompson
in reply to Sonny

Will Thompson
Will Thompson
• •
@popey I agree that access to services on localhost is higher-privilege than access to services on the LAN, which is in turn higher privilege than access to the internet. I fundamentally disagree with the premise that access to the internet is something that should be flagged to end-users as a cause for concern. The ability to work offline, by contrast, seems interesting to highlight as a positive.
@popey
in reply to popey

James Henstridge
James Henstridge
• •

@popey @wjt Also, presumably a cryptocurrency scam app could steal the user's funds by talking to the same network hosts as a legitimate app would.

How do you distinguish network traffic representing a transaction the user wanted to make from network traffic representing a transaction the user didn't want to make?

@popey @Will Thompson
in reply to James Henstridge

Sonny
Sonny
• •

@jamesh @popey @wjt

https://floss.social/@sonny/112161056007032368

Sonny

2024-03-26 08:31:34


@popey @wjt

Good to know 👍

I don't want to focus too much on that case in the conversation.

It's a solved one for us by acknowledging that completely unrestricted network access is unsafe and doing manual reviews.

The way forward is how to consider apps with network needs as safe. Building a portal/API will bring a reasonable compromise.

As always, we'll make sure to share whatever we come up with.


@popey @Will Thompson @James Henstridge
in reply to Sonny

James Henstridge
James Henstridge
• •

@popey @wjt If you are relying on manual review and/or trust in the publisher to weed out malicious apps, then what additional benefit does the portal bring?

That seems particularly relevant if a malicious app that escapes the review process can do its thing with the same portal prompts the user would expect for the type of app it purports to be.

@popey @Will Thompson
in reply to Sonny

Lennart Poettering
Lennart Poettering
• •

and i think a dns angle matters. I.e. local name resolution (i.e. via mdns and search domains) should be more privileged than resolving fqdns.

Impl. idea: define an xattr on cgroups that app sandbox reads and resolved reads and honours.

in reply to Sonny

Val Packett
Val Packett
• •

I really really wish it would be a capability based API, i.e. the portal taking a host (and socket type etc) and responding with an opened socket fd-passed, and that being the only way to connect to anything. (And the document portal should likewise do fd-passing instead of mounting magic FUSE filesystems..)

but of course that’s probably too much API change inflicted on app developers and we’ll always be stuck with janky sandboxes :(

in reply to Val Packett

Sonny
Sonny
• •

@valpackett

We might end up with a new API for apps to implement to make this work anyway.

Personally I'd already be happy with "this app is requesting network access, do you want to allow it" yes/no

@Val Packett
in reply to Sonny

Felicitas Pojtinger 🇨🇦
Felicitas Pojtinger 🇨🇦
• •
Don't have the skills necessary to work on this I'm afraid, but I'd love to test this in Multiplex given that it's a bit of a unique networked usecase (P2P/BitTorrent + WebRTC)
in reply to Sonny

Profile13115
Profile13115
• •

There has to be an easy option to "torify" flatpaks aka using proxys. This currently is a huge inconsistent mess; some apps use system proxy settings, some use "hardcoded" proxy variables, others ignore all proxy variables completely, some have proxy settings inside the apps themselves.

It has to be easy for a user to use a proxy for flatpaks, mainly in the lights that many people have to leverage the Tor network for many things that are outside of the day to day internet activities.

in reply to Sonny

Sebastian Wick
Sebastian Wick
• •
I hope this will focus on the important parts: separating access to the host, access to the local network and access to the internet. portals for this very much seem like wasted resources to me.
⇧