Flatpaks, sandboxes and security
ramcq.net/2018/10/12/flatpak-sandbox-security/Posted Oct 15, 2018, 2:55 PM UTC
58161
ramcq.net
Unrestricted access to the PulseAudio socket allows you to reconfigure audio routing, capture microphone input, etc. To ensure user consent we need a portal to control this, where by default you can play audio back but device access needs consent and work is under way to create this portal.
It seems like a centralized audio server should be able to handle policy like this itself... maybe take some notes for pipewire.
13
Sandboxing has always been a design goal for Pipewire.
18
So I kind of admire the flexibility and modularity of pipewire in this regard, but don't you feel that portals that are implemented over dbus, it would have been easier to make the model of privilege management more implicit and simpler by using some sort of capability based IPC?
I have used dbus in the past, aside from various things I consider a little "overengineered" in the protocol, it does work fine mostly. There is certainly nothing as featureful as it is, in the Linux ecosystem. My main gripe is usually the "checking privs at method call time" and not some way to open a reference to some interface and then easily drop privileges for the rest of the time. Unix has these semantics (and has had them since its inception) in the form of file descriptors. The way dbus's semantics work make it hard to implement designs centered around privilege separation in clients that need access to protected interfaces, and lead to things like policykit (or other policy mechanisms on top, putting the pain of management on the administrator).
Now, pipewire still allows one to not use dbus but something like what I described, but why were portals still chosen, were alternative designs considered?
The reason I am asking this is because this particular 'weakness' was pointed out during the kdbus days too, and back then the core motivation was still using it for portal like mechanisms, which is why credential passing was so heavily used (and making it kernel enforced prevents clients from faking things).
On Android, binder doesn't have this issue.
BUS1 was great in this aspect, processes had referenences as handles to different peers, and you could revoke them, thus using it as a capability mechanism.
3
Good to hear. I hope to see Pipewire mature further!
2
As a user I feel I am back in a rpm vs deb situation where as result of Ubuntu's popularity most third party developers have opted for either snap or AppImage.
3
Really? I see most people opting for Flatpak.
3
It doesn't seem so. Checkout the the snap store. It has verified accounts for AWS, Jetbrains, Skype, Spotify, DigitalOcean, Plex, Nextcloud, and so on. None of them are on Flathub. Technically, they don't have to but they made a conscious decision of selecting Snap over Flatpak.
3
Hmm. I suppose it's more of a proprietary vs open source thing. Proprietary software seems to be on Snap more, from what you said, whereas my experience is more with open source software opting for Flatpak.
2
Canonical has paid outreach/packagers and can sell the fact that it is just Ubuntu so Ubuntu packages work with fewer modifications (even able to disable sandboxing). Flathub has none of that which you can view as a negative but is because its more community driven, requires sandboxing, and independent of any distro.
1
A great overview. I hope this will help to clear up some of the misinformation going around lately.
2
[deleted]
2
Bubblewrap is basically just a thin wrapper around Linux namespaces, to remove the need for an application itself to set up its own sandbox.
I'm not sure how well the namespaces are audited, but I assume that they're considered secure enough for use.
2
>At Endless OS, Flatpak literally changed the structure of our engineering team, and for the first time allowed us to develop and deliver our OS, SDK and apps in independent teams each with their own cadence.
Every professionally developed operating system maintains some distinction between a "base platform" -- the responsibility of the OS developers -- and the user facing applications which interact with the system only through well-defined APIs.
-3†
Not really—that's the thing about a lot of "Linux distrubtions" and many other systems; due tot he fact that Linux is only a kernel and not a complete OS how most of those systems are formed is that the people who bundle together everything into a working OS are a different working group from those who progroammed all those things that are bundled together.
On FreeBSD or Windows what the "base system" is is fairly clear; it's what is developed by FreeBSD and MS. On Debian it isn't since very few things are and the only major thing really is the package manager. Debian was the first system to create package management as we know it today; originally the idea was to use this only for the "base system" but they quickly realized that that distinction was meaningless and more and more stuff was added to the package repository because it is meaningless without a development model like FreeBSD or Windows it becomes a very meaningless question to ask what is "base system" and what is "add on" any more; the question is simply not relevant for anything; it's a completely meaningless distinction.
I mean on Windows things are part of the "base system" that include things like font sets, icon themes, media players, file managers, internet browsers that historically on Unix have never been but they are developed as MS and shipped as one monolithic block with Windows.
Like over at r/pcmasterrace there recently was a topic where they complained about Windows Explorer and I pointed out to them that even on Windows nothing actually stops you from using a third party file manager and it seemed to blow the minds of some of them; they've been so accustomed to the idea that you just use Windows Exporer that they never thought of the idea that you research what file manager you want and pick what is best for you.
27
The Linux desktop does not have those well-defined APIs.
There are tons of custom services that expose various APIs in various forms of stability available in various combinations and versions depending on what distro and what desktop you are running today, but there is no coherent set of well-defined APIs.
24
Would you mind listing a couple of those APIs ?
2
Sure, for loading JPEG images, you can for example use:
libjpeg, libjpeg-turbo, turbojpeg, ImageMagick, gdk-pixbuf, GEGL, QImageReader, QImage, QPixmap - and those are just the ones I know.
12
And you want a "base platform" for loading jpegs ? What does loading a jpeg have with flatpak ? Loading a jpeg is an I/O operation, in that the only contact point between the program and anything else is an open() followed by a read() (or mmap()).
Also, libjpeg is the standard. libjpeg-turbo is a drop-in replacement for libjpeg, with assembly optimizations.
3†
The Linux desktop does not have those well-defined APIs.
It definitely does, but devs don't like sticking with bare POSIX primitives because it's not new and shiny enough.
-3†
How do I open a window in POSIX?
In particular, I'm looking for POSIX's equivalent to the win32 CreateWindowEx() function. Which is kind of the minimum thing every GUI platform must provide.
16
How do I open a window in POSIX?
In particular, I'm looking for POSIX's equivalent to the win32 CreateWindowEx() function. Which is kind of the minimum thing every GUI platform must provide.
You would open and map memory using two posix functions open(2), then mmap(2) and write directly to memory.
It's not the minimum, you have a few layers that are more critical than create window, like how does your window get and handle message events? A window is useless without user input, and a complete GUI layer. POSIX is about being portable so defining bloated userspace API's is out of scope, stick with direct memory mapped "windows" and it will work every OS that has a means to map a file to memory for graphics rendering.
If you want multiple "windows" cooperating and sharing the same input stream then you are going to have to modify the Linux kernel a bit, maybe other POSIX based OS's handle graphical user IO more elegantly, I think plan9 has a more robust /dev/fb setup than Linux.
0†
You open a Unix Domain Socket (a POSIX thing) and communicate with Xorg using the X11 protocol. Similar how you "open" (make) a window in wayland. You can use the xcb library, or xlib, to make it a bit easier.
How do you open a file in flatpak ?
-5
Sadly, POSIX has quite a few limitations where the kernel offers better APIs, and POSIX perhaps misses a lot of things that are useful to implement a full blown desktop environment. Glib infact is cross platform and heavily uses POSIX and portable code.
I think their point was rather that libraries break compatibility very easily in the userspace, which is true (and has always been).
Even the kernel has broken compat a lot of times, I think the only place where developers are extremely careful is the syscall interface.
6
Sadly, POSIX has quite a few limitations
Not really, what kind of limitations are you seeing?
POSIX perhaps misses a lot of things that are useful to implement a full blown desktop environment.
What does it miss, what are you trying to do it's most likely possible and you are unaware of the means to accomplish your goals.
I think their point was rather that libraries break compatibility very easily in the userspace, which is true (and has always been).
So just use the POSIX primitives which do not break, instead of junk libs.
1
I don't understand, did you mean to imply that ubuntu, suse and rhel aren't professionally developed?
5
flatpaks are not very efficient in regard to RAM usage relative to traditional systems. Given that Endless is targeting low-end systems ... why would you incur this penalty in regard to RAM?
2
Does 2MB of duplication matter a ton when a single browser tab uses 200MB? Obviously it could be better but the trade off is they can share the workload of packaging and have an attractive platform for third parties to target.
6
-
200MB per tab? Stop spouting nonsense. I've got 30 tabs open right now and it's consuming maybe 600MB total. If you're using firefox look at about:memory and figure out the actually committed RAM. Chromium is certain to have something similar.
-
Their typical machine has just 2GB RAM (one has 1GB and another, their "enterprise", has an optional 4GB max). They are not really targeting "browsing", so the browsing comparison is a pointless distraction. They are targeting non-connected and low-bandwidth usage and even bundled a downloaded (subset of) wikipedia.
-
And where do you get 2MB? That's also nonsense ... or are you forgetting the double-loading of any duplicate system libraries? That's the point I was making (or trying to). These machines are slow and resource constrained, so everything that you would argue in favor for non-static linking ... should argue against flatpak usage. It's like using appimage on constrained machines ... you just wouldn't make that the default bundling.
1
200MB per tab? Stop spouting nonsense. I've got 30 tabs open right now and it's consuming maybe 600MB total.
Firefox shares web processes more so yes it uses much less memory (and is less secure/robust because of it). EndlessOS uses Chromium I do believe and here is my real world current usage: https://i.imgur.com/BZXuW8c.png (list goes on but stays around 60MB per tab below that).
And where do you get 2MB? That's also nonsense ... or are you forgetting the double-loading of any duplicate system libraries? That's the point I was making (or trying to).
The OS is pretty minimal at least so you are probably talking about a dozen libraries that are duplicated. Is 2MB a bit low, sure, is it still smaller than a single tab in even Firefox, yes.
It's like using appimage on constrained machines ... you just wouldn't make that the default bundling.
No it is much better than that since most libs are still shared between Flatpaks.
2
[deleted]
-7†
Why would you care about sandboxing third-party applications when the base OS cannot be trusted? Flatpak could be awesome and certainly has benefits. My biggest concern is that OS vendors should not become the gatekeepers of what FOSS application developers can or cannot do.
-8
Everybody is free to grant an app from a flatpak full root privileges. Flatpak is not in the business from stopping you from shooting yourself in the foot if you absolutely want to.
Flatpak is in the business of making you not shoot yourself in the foot by accident when an app developer pushed an update that accidentally did rm -rf $HOME/ .config/$APPNAME in its installer.
16
Can you upgrade the OS supplied flatpak with an upgraded version through flatpak?
2
That isn't what Flatpak is designed to do, so while its technically possible with some really ugly hacks the practical answer is no.
7
Sure, the issue is that there are now two channels. An OS vendor stream and a user application stream. The user stream can and, if android or any other mainstream linux device is any example, will be limited to restricted OS operations. Meaning the OS vendor is now in control to limit and do whatever it wants with its third parties. If you take Endless for example; can you upgrade the system components yourself or are you dependent on what they provide?
Of course for the regular FOSS distributions this is irrelevant.
1
If the OS is provided as a flatpak, sure you can.
2
Like root on android :)
1
Flatpack entirely fails the Linux principle; do one thing and do it well. Either be a delivery system or be a sandbox. There is no reason for a delivery system to be anything else.
Besides, sandboxing done properly, is the responsibility of the OS, it should be part of the kernel. It can't be an optional extra because any program wanting to do something unsafe will simply opt out. Besides, I thought we trusted OSS to provide security in a more real way than any sandbox.
On that note, I can't see a huge problem with the delivery systems that exist. I think Flatpack is attaching a problem (sandboxing) to something that doesn't have one so that it appears to add value.
-16
Flatpack entirely fails the Linux principle; do one thing and do it well. Either be a delivery system or be a sandbox.
Actually, flatpak is neither.
The delivery part is ostree.
The sandbox part is bubblewrap. And yes, it uses kernel primitives and other kernel tools and then builds a sandbox on top of them.
Flatpak is a set of tools and conventions built on top of these. You know, standing on the shoulders of giants. Each doing one thing and doing it well.
22
Interesting. I had no idea flatpak was implemented on top of user namespaces. Have the issues been ironed out? It seems user namespaces exposed a lot of attack surface in the form of previously root-only programs.
1
AFAIK they allow only subset of capabilities possible in user namespaces, so they avoid (some?) attack vectors.
1
That's not the Linux principle, that's the Unix philosophy and as we all know, GNU is Not Unix.
Other well-known programs that don't fall into that philosophy include X11, modern web browsers, CUPS, desktop environments, a lot of GNU's tools, etc.
11
That's not the Linux principle, that's the Unix philosophy and as we all know, GNU is Not Unix.
I cannot help but laugh at this.
GNU is Not Unix doesn't literally mean that it isn't Unix-like, it was to shun proprietary Unices back when the project was established, to provide free alternatives to their tools. Though I wouldn't argue that RMS and a lot of GNU devs are compatible at any rate with Unix even back then, they're lispers (which is why you see GNU embracing Guile as an extension language), and that their tools are small and not adding unneeded functionality (sed --sandbox, anyone?).
Fortunately, the Linux kernel doesn't have a preferred userspace so you can stick to whatever tools you want, or go entirely GNU free too (except perhaps the compiler chain, and clang doesn't support building the kernel (yet)).
But again, the fact that certain tools don't do something in a rather simpler way is no excuse to keep repeating the same mistake again.
The goal is incremental improvement, not to regress.
0
IIRC Stallman doesn't like Unix. He chose to make GNU Unix-like for compatibility only.
3
He has no choice anyway. His favorite OS is long dead.
1
a lot of GNU's tools,
A lot? Such as?
-1
Basically all of them. Here's "echo" for example, but if you look at "cat" or "ls" you'll find the same thing. The GNU version is loaded with feature flags, ones that sometimes duplicate functionality you could get by chaining tools together, and the BSD / Unix ones are 3-4x shorter and sometimes more.
https://gist.github.com/fogus/1094067
Emacs is another example of a tool that says "fuck the Unix philosphy" and is generally quite loved as a result.
5
I would be careful putting Emacs in the same bucket as others (although I agree).
Emacs happens to be a lisp interpreter at its core that is used to implement a text editor, rather. Look at how easily you can embed other things into it, it doesn't necessarily need a plugin architecture, by design. That is a strength, and the origins of such a design can be traced back to the Lisp Machine, which had a lot of interesting things back then current Unices lack.
Another interesting fact, unrelated, (since I've had the privilege of looking into one of the real Lisp Machines) is that you could dynamically trace the kernel and modify the data structures directly, similar to what BPF allows you today or what /proc and /sys do, but with a lot less heavylifting. I think one of them even was a true SSI which could share a single address space abstraction the OS implemented over the network, but don't count my word on that, I can't find the reference.
1
Basically all of them. Here's "echo" for example, but if you look at "cat" or "ls" you'll find the same thing.
What will I find exactly, a more robust tool that does it's job better than some half assed BSD util? More command line options means it's monolithic design eh? I'll give you EMACS, but that's the only one I can agree with.
1
It does one thing and one thing only: run apps
Surprisingly, running apps well is quite hard.
9
It also downloads, updates and secures apps. In fact, running them is what it doesn't do, that's up to the OS.
2
Runing apps well requires downloading, updating and securing them.
8
Come on now, you know perfectly well what 'run' means. Stop the silly game.
2
Yet another blog post about how flatpak is the greatest thing since ever.
The poster is a Flatpak.org Dev/teammember. They've all been spamming Linux sub reddits with this garbage.
[deleted]
No, I want a minimum of objectivity, realism, and facts-based discussion.
And any claim the flatpack security debacle "it's no big deal" isn't that: It's pure fanboyism and the furthering of agendas, nothing more.
Suffice to say that one of the reasons why Flatpack is "literally hitler" is because Flatpack and Snap advocates had to systematically discredit AppImage (a community driven solution which is orders of magnitude simpler, more elegant, and doesn't rely on specialized "distribution channels") for their pet projects to be able to assert themselves, and did so by claiming it AppImages where insecure because they lacked sanboxing, the very same sanboxing features Flatpack claimed have but, as it turns out, are actually not enabled by default and entirely up to the developer's discretion.
Flatpack is also "literally Hitler" because I'm pretty sure this got marketed as being ready for widespread adoption (thereby exposing everyone to all sorts of security risks), even though it clearly wasn't (because it lacked the mechanisms necessary for applications to work properly in a fully contained environment, which are now being developed and are called Portals, which is why they had to make sanboxing optional in the first place) was because Canonical had already announced Snap, and Red Had (the guys funding the development of Flat Pack) felt like they had to get it out the door before it was ready to prevent ISVs from standardizing around it.
That's why Flatpack is "literally Hitler".
There's AppImage. There's Snap. Flatpack is not the only player, and it's not the standard regardless of how you feel about it.
And hopefully, it never will become the standard, because IMO the Linux community should not enable projects that place corporate greed over user safety.
IMO ISV's and users are better off with AppImage instead: It's independent, it doeasn't require additional software, it has no specialized distribution channel (this isn't a bug, it's a feature), it's simpler, it's easier for both packagers and users, and best of all FireJail provides actual sanboxing.
Done and done, Red Hat and Canonical can save a couple of million each!
EDIT: My point being... for all the talk about Flatpack, why not AppImage? And no, "AppImage is not secure" doesn't work anymore...
How's this for software distribution?? (mark it as executable if you need to)
Says the person who engages in conspiracy theories accusing Red Hat of employing astroturfing, defends Canonical's killed-off solutions as "better" (yet fails to back it up with "facts" when asked to do so), and blames Red Hat for killing the Linux desktop instead of Microsoft, you know, the company that's been actually proven guilty of smothering Linux and succeeding.
(From this comment thread: https://www.reddit.com/r/linux/comments/9n50ba/lets_see_why_flatpak_and_sandboxing_are_awesome/e7mbxhb/?context=3)
Edit: parentheses
AppImage doesn't solve the same problems as Snap or Flatpak. There's no infrastructure for updates around it whatsoever. By the time you build that you're 50% of the way to having Snap and Flatpak again.
AppImage, like I said, has no update mechanism. It's functionally equivalent to a statically linked binary. How is that more secure?
This is FALSE. Quit spreading misinformation.
Another source, more up to date.
The problem is not the flatpak defaults, the problem is that apps opt-out of them. I'll get to this more in a second.
Again, False. Portals have been around for a while now, they are not "being developed". They were already working with all the basic cases covered two years ago.
Quote from that page:
That was 2.25 years ago.
So why do a lot of apps disable the sandbox instead of using Portals? Because a lot of apps are still on Gtk 2 or Qt 4, so they can't use Portals, so they gave to disable the sandbox. Or they are using Gtk 3 / Qt 5 but they haven't put in the effort to use Portals yet, because it's not magic and the app writer does have to do some work to support them. But it's not the default, it's something the packager has to choose to do.
So much for "facts-based discussion". Do some basic research before spreading FUD please.
[deleted]
Yo does Snap still make ~/snap? Because if so, fuck Snap.
Failing to disclose possible conflicts of interest doesn't inspire people to trust you.
The sandbox isn't controlled by the user as far as I know. The creator of each flatpak controls how the sandboxing works. It seems many flatpaks allow writing to the user's home directory because the application would have to be modified otherwise; that's equivalent to no sandbox at all.
It's really not. The Linux kernel goes to extreme lengths to maintain the kernel-to-user space ABI. Breaking that interface causes Linus to scream at you until you fix it. If I remember correctly, they were able to get executables compiled as far back as the 90s and run them on modern kernels.
If you statically link your libraries, you end up with an executable that is guaranteed to run on any distribution.
Not really. Especially if you tell users that it's secure and later it turns out not to be secure. Looks like flatpaks even have little shield icons and everything.
All permissions are easily overrided in flatpak. Ie flatpak override org.flatpak.qtdemo --user --nofilesystem=home
Get a hold of yourself. Really "hitler"??? A discussion on the Pro's/Con's of flatpaks is one thing. A handful of users bombarding Reddit with "flatpaks are the shit!" posts is another. The same users downvoting anyone who attempts to discuss the "cons" part also doesn't help. Y'all look like the worst kind of circle jerk. I never once stated ANYTHING remotely close to "flatpaks are bad"; I have stated I don't care for them, but that's a damn far cry from "hitler". Notice though, you are voted up 9 points, for accusing someone of shit they didn't do. THIS is why the discussion on flatpaks won't go anywhere. You all can convince yourselves of how awesome they are in peace. I have zero interest in discussing any of the Con's, because the flatpak.org maintainers will just shout it down. Meanwhile, most linux users, who don't like them for WHATEVER reasons, will quietly not use them. The "whatever" reasons will not be addressed because of people like you creating a childish environment that adults don't want to partake in.
[deleted]
[deleted]
And all the marketing paid by ... surprise, surprise ... red hat
Pay no mind to the man behind the curtain...