Creating a Flatpak for Linux #1053

syhlx · 2024-05-01T15:29:37Z

I'm building a Flatpak to make it easier to distribute and update Cromite across all Linux distributions.

Everything is about ready and seems to work fine. I just need a few things:

Could you add the chrome-sandbox target for the next release to allow Flatpak to take over the sandboxing?
Do you have an SVG version of Cromite's logo that I could include? (for now, I made a dirty SVG conversion from the PNG logo)
Is the package name "com.github.uazo.cromite" OK for you or would you prefer something else?

uazo · 2024-05-01T15:55:36Z

Sorry for the ignorance, is something that respects what has been requested in #771 ?

I'm building a Flatpak to make it easier to distribute and update Cromite across all Linux distributions.

Let me get this straight, how can users verify the source of the package? the file is not signed in any way.

Could you add the chrome-sandbox target for the next release to allow Flatpak to take over the sandboxing?

allow me time to read up on it.
I anticipate that I am already at the threshold of the maximum 24 hours tied to the runner, so I have to revise the action of the build also to add the android webview, I don't think I will be able to do it that fast.

Do you have an SVG version of Cromite's logo that I could include?

#429 (comment)

Is the package name "com.github.uazo.cromite" OK for you or would you prefer something else?

currently for android is org.cromite.cromite, it would be better to use the same.

syhlx · 2024-05-01T16:40:10Z

Sorry for the ignorance, is something that respects what has been requested in #771 ?

This would, indeed, solve the issue of Auto update on Linux #771 which suggested using a script for it (and also #890 & #621).

Let me get this straight, how can users verify the source of the package? the file is not signed in any way.

The Flatpak would be hosted on Flathub.org and the manifest would be public.
The files for Cromite are pulled directly from your github release (see line 81 of the manifest).

Here is what the Flatpak manifest looks like so far :

app-id: org.cromite.cromite
runtime: org.freedesktop.Platform
runtime-version: '23.08'
sdk: org.freedesktop.Sdk
base: org.chromium.Chromium.BaseApp
base-version: '23.08'
command: cromite
separate-locales: false
finish-args:
  - --allow=multiarch
  - --device=all
  - --env=GTK_PATH=/app/lib/gtkmodules
  - --env=XCURSOR_PATH=/run/host/user-share/icons:/run/host/share/icons
  - --share=ipc
  - --share=network
  - --socket=cups
  - --socket=pcsc # FIDO2
  - --socket=pulseaudio
  - --socket=x11
  - --socket=wayland
  - --require-version=1.8.2
  - --system-talk-name=org.freedesktop.UPower
  - --talk-name=org.freedesktop.FileManager1
  - --talk-name=org.freedesktop.Notifications
  - --talk-name=org.freedesktop.ScreenSaver
  - --talk-name=org.freedesktop.secrets
  - --talk-name=org.kde.kwalletd5
  - --talk-name=org.kde.kwalletd6
  - --talk-name=org.gnome.SessionManager
  - --talk-name=org.gnome.Mutter.IdleMonitor.*
  - --system-talk-name=org.freedesktop.Avahi
  - --own-name=org.mpris.MediaPlayer2.chromium.*
  - --filesystem=xdg-run/pipewire-0
  # To load policies on the host /etc/chromium/policies
  - --filesystem=host-etc
  # To install a PWA application
  - --filesystem=home/.local/share/applications:create
  - --filesystem=home/.local/share/icons:create
  - --filesystem=xdg-desktop
  # For default download directory to work as expected
  - --filesystem=xdg-download
  # For GNOME proxy resolution
  - --filesystem=xdg-run/dconf
  - --filesystem=~/.config/dconf:ro
  - --talk-name=ca.desrt.dconf
  - --env=DCONF_USER_CONFIG_DIR=.config/dconf
  - --env=GIO_EXTRA_MODULES=/app/lib/gio/modules
  - --env=GSETTINGS_BACKEND=dconf
  # For KDE proxy resolution (KDE5 only)
  - --filesystem=~/.config/kioslaverc
  - --filesystem=/run/.heim_org.h5l.kcm-socket
  - --persist=.pki

modules:
  - name: zypak
    sources:
      - type: git
        url: https://github.com/refi64/zypak
        tag: v2024.01.17
        commit: ded79a2f8a509adc21834b95a9892073d4a91fdc
        x-checker-data:
          type: git
          tag-pattern: ^v([\d.]+)$

  - name: cromite
    buildsystem: simple
    build-commands:
      - mkdir -p /app
      - bsdtar -xf cromite.tar.gz -C /app
      - mv /app/chrome-lin /app/cromite
      - mv /app/cromite/chrome /app/cromite/cromite
      - install -Dm 644 LICENSE /app/cromite/LICENSE
      - install -Dm 644 cromite.desktop /app/share/applications/org.cromite.cromite.desktop
      - install -Dm 644 cromite.svg /app/share/icons/hicolor/scalable/apps/org.cromite.cromite.svg
      - install -Dm 755 cromite.sh /app/bin/cromite
      - install -Dm 644 -t /app/etc cobalt.ini
      - install -Dm 644 -t /app/share/metainfo org.cromite.cromite.metainfo.xml

    sources:
      - type: file
        url: https://github.com/uazo/cromite/releases/download/v124.0.6367.91-16f4295a45228d50667be3dc7463efde9f3002f6/chrome-lin64.tar.gz
        sha256: 01d253e2cd3380a4116eb6adebb127dcf12ba670599a9192f77f7996736fe3c2
        dest-filename: cromite.tar.gz
        only-arches: [x86_64]
      - type: file
        path: cobalt.ini
      - type: file
        path: org.cromite.cromite.metainfo.xml
      - type: file
        path: LICENSE
      - type: file
        path: cromite.svg
      - type: file
        path: cromite.desktop
      - type: file
        path: cromite.sh

allow me time to read up on it. I anticipate that I am already at the threshold of the maximum 24 hours tied to the runner, so I have to revise the action of the build also to add the android webview, I don't think I will be able to do it that fast.

No problem.

Basically, when you call Ninja, you can add the build target:

ninja -C out/lin64 chrome chrome_sandbox

It usually take a few seconds to build, but I don't know how much compute time it represents on Github.

#429 (comment)

Perfect!
Sorry, I didn't even think to check existing issues for this...

currently for android is org.cromite.cromite, it would be better to use the same.

Indeed.

uazo · 2024-05-01T18:45:38Z

thank you for your answers.

The Flatpak would be hosted on Flathub.org

So I should create a login, and then what? Can you give me any other pointers?

Here is what the Flatpak manifest looks like so far :

url: https://github.com/uazo/cromite/releases/download/v124.0.6367.91-16f4295a45228d50667be3dc7463efde9f3002f6/chrome-lin64.tar.gz
sha256: 01d253e2cd3380a4116eb6adebb127dcf12ba670599a9192f77f7996736fe3c2

How would I update this information?

syhlx · 2024-05-01T20:00:16Z

So I should create a login, and then what? Can you give me any other pointers?

I have uploaded all the files to Github.
Please note that, currently, it requires the "chrome-sandbox" file to work. Cromite will not open without it.

To publish it on Flathub, they have a short section on their documentation for it: How to submit an app.

You might want to edit the "org.cromite.cromite.metainfo.xml" to change the description and/or add screenshots.
It is the file that is going to govern how Cromite's page will look on Flathub (example: ungoogled-chromium on Flathub)

url: https://github.com/uazo/cromite/releases/download/v124.0.6367.91-16f4295a45228d50667be3dc7463efde9f3002f6/chrome-lin64.tar.gz
sha256: 01d253e2cd3380a4116eb6adebb127dcf12ba670599a9192f77f7996736fe3c2

How would I update this information?

The URL for the file is "https://github.com/uazo/cromite/releases/download/" + [Your Github Release Tag] + "/chrome-lin64.tar.gz"

The sha256 is the checksum of the "chrome-lin64.tar.gz" that you create during Cromite's build.

sha256sum chrome-lin64.tar.gz

uazo · 2024-05-03T06:46:46Z

thank you very much for your suggestions.
I will look into it!

syhlx · 2024-05-04T10:48:53Z

FYI, I added a readme with basic instructions to test the Flatpak.

AlphaElwedritsch · 2024-05-17T06:00:00Z

any news here?

olumolu · 2024-05-19T10:44:33Z

Can you make it all corners rounded to make it better looking in gtk4 desktop like gnome.

#1053 add chrome_sandbox

uazo · 2024-05-21T11:16:16Z

@syhlx as far as chrome-sandbox is concerned, I understand from https://issues.chromium.org/issues/40338793 that it is no longer necessary.
why then should I release that executable?

uazo · 2024-05-21T11:49:17Z

um. i was looking at your repo. i guess it is too complex for me, i am not able to assess what all those permissions in https://github.com/syhlx/cromite-flatpak/blob/main/org.cromite.cromite.yaml mean. but that seems to me to be the minimum necessary, correct?

another thing, in https://github.com/syhlx/cromite-flatpak/blob/main/cromite.sh you use the file /etc/chromium/policies, why?
so we would eliminate this one, which seems excessive to me:

  # To load policies on the host /etc/chromium/policies
  - --filesystem=host-etc

if it can be done.

again:

 To install a PWA application

can be removed, as the PWA are not supported.

why then should I release that executable?

ah maybe I understand, is it to make zypak work? and why is zypak needed, otherwise the flatpack sandbox won't work?

Sorry to bother you, but I am ignorant on the subject.

syhlx · 2024-05-21T13:41:59Z

@syhlx as far as chrome-sandbox is concerned, I understand from https://issues.chromium.org/issues/40338793 that it is no longer necessary. why then should I release that executable?

When running Chromium directly on the system as normal application, the chrome-sandbox binary is, indeed, not used anymore. Chromium now uses the Linux kernel's unprivileged user namespaces.

However, since Flatpak sandboxes everything, Chromium will generate the following error if run without SUID, as Flatpak will not allow it to use unprivileged user namespaces:

FATAL:zygote_host_impl_linux.cc(126)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.

um. i was looking at your repo. i guess it is too complex for me, i am not able to assess what all those permissions in https://github.com/syhlx/cromite-flatpak/blob/main/org.cromite.cromite.yaml mean. but that seems to me to be the minimum necessary, correct?

Here is a little more details about each permission:

Details

# Allow non x86_64 binaries to run (eg. an extension was meant for 32-bits systems)
# Not strictly required and we should probably not include it by default as extensions should not use binaries anyway...
- --allow=multiarch
# Allow access to all devices (GPU, webcam, input devices...)
- --device=all
# I forgot to remove this environment variable... I'll remove it in my repo
- --env=GTK_PATH=/app/lib/gtkmodules
# Environment variable to point to mouse cursor icons (in case the user uses a custom mouse cursor theme)
- --env=XCURSOR_PATH=/run/host/user-share/icons:/run/host/share/icons
# Inter-process communication to allow Cromite to send/receive communication to/from other processes
- --share=ipc
# Access the network
- --share=network
# Access to printers
- --socket=cups
# Access to smartcards, YubiKeys...
- --socket=pcsc # FIDO2
# Access to the sound system
- --socket=pulseaudio
# Use Linux's old graphical server
- --socket=x11
# Use Linux's new graphical server
- --socket=wayland
# Require Flatpak version >1.8.2 (Older versions will not work properly)
- --require-version=1.8.2
# Access to power information (Battery level, power connected). Also includes the power level of gaming controllers and other accessories
- --system-talk-name=org.freedesktop.UPower
# Open file picker to open a file (eg. uploads)
# This allows users to select a file outside of the allowed paths for Cromite
- --talk-name=org.freedesktop.FileManager1
# Allows users to receive notifications from Cromite
- --talk-name=org.freedesktop.Notifications
# Allows Cromite to inhibit/prevent the screensaver (eg. when playing a video)
- --talk-name=org.freedesktop.ScreenSaver
# Allows Cromite to store passwords and keys into a compatible "keyring" / "wallet"
- --talk-name=org.freedesktop.secrets
# KDE (desktop environment) has a seperate service to access KDE Wallet for each version
- --talk-name=org.kde.kwalletd5
- --talk-name=org.kde.kwalletd6
# Interface with Gnome (desktop environment)
- --talk-name=org.gnome.SessionManager
# Tell Gnome's window manager if Cromite is idle (eg. to prevent screensaver while watching a video)
- --talk-name=org.gnome.Mutter.IdleMonitor.*
# To access multicast DNS and ZeroConf devices on the network (media centers, NAS, printer UIs...)
- --system-talk-name=org.freedesktop.Avahi
# Allow Cromite to tell the rest of the system what media content it is currently playing (Name of a video, music artist...)
# Also allows Cromite to receive Play/Pause, Next, Previous requests while playing media content
- --own-name=org.mpris.MediaPlayer2.chromium.*
# Access to the new sound server. Also allows screen sharing (eg. for webmeetings)
- --filesystem=xdg-run/pipewire-0
# Access to system policies for Chromium-based browsers
# Either set by an organisation for their employees or by a user to enforce certain features / settings in Cromite
- --filesystem=host-etc
# To install a PWA application -> Since it is not supported in Cromite, no point in keeping it
- --filesystem=home/.local/share/applications:create
- --filesystem=home/.local/share/icons:create
- --filesystem=xdg-desktop
# For default download directory to work as expected
- --filesystem=xdg-download
# Detect what proxy settings are set in Gnome
- --filesystem=xdg-run/dconf
- --filesystem=~/.config/dconf:ro
- --talk-name=ca.desrt.dconf
# Detect what proxy settings are set in KDE 5
- --filesystem=~/.config/kioslaverc
- --filesystem=/run/.heim_org.h5l.kcm-socket
# Fixes this: https://github.com/flathub/com.github.Eloston.UngoogledChromium/issues/34
- --persist=.pki

Users can also control these permissions as they see fit using either Flatpak's CLI or a GUI tool like Flatseal:

Details

another thing, in https://github.com/syhlx/cromite-flatpak/blob/main/cromite.sh you use the file /etc/chromium/policies, why? so we would eliminate this one, which seems excessive to me:
  # To load policies on the host /etc/chromium/policies
  - --filesystem=host-etc

The /etc inside of the Flatpak sandbox is not the system's /etc.
Flatpak exposes the host's /etc in /run/host/etc to the app.

The bash script is a very inelegant way to copy the host's policies inside of the Flatpak sandbox's /etc where Cromite is going to look for the files. I'll see if I can find a cleaner way to do this.

can be removed, as the PWA are not supported.

Not point in keeping it, then. I'll remove it.

ah maybe I understand, is it to make zypak work? and why is zypak needed, otherwise the flatpack sandbox won't work?

It is indeed for Zypak.

Zypak acts as a middleman between chrome-sandbox and Flatpak for the sandboxing in order to make sure that every process is properly opened the "Flatpak way" while keeping Cromite's sandbox running properly.

Sorry to bother you, but I am ignorant on the subject.

No worries. I'm here to help!

uazo · 2024-05-21T15:20:20Z

Users can also control these permissions as they see fit using either Flatpak's CLI or a GUI tool like Flatseal:

perfect!

Allows users to receive notifications from Cromite

as before, unsupported, you can delete it.

However, since Flatpak sandboxes everything, Chromium will generate the following error if run without SUID, as Flatpak will not allow it to use unprivileged user namespaces

OK, that's clear. but where is the sudo chown of chrome-sandbox launched? or the launching of Zypak?

It allows users and organisations to enforce certain features/settings

I realise this, but it should not be by default.

Zypak acts as a middleman between chrome-sandbox and Flatpak for the sandboxing in order to make sure that every process is properly opened the "Flatpak way" while keeping Cromite's sandbox running properly.

technically I don't like it, Having another implementation made not by the chromium team on a component as sensitive as the sandbox does not inspire me with confidence.

searching I found https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch but I don't know exactly what it is.

I guess the sandbox problem is a big one: what tells me that flatpak's sandbox is better than chromium's?

syhlx · 2024-05-21T16:48:03Z

as before, unsupported, you can delete it.

OK. I'll remove it.

OK, that's clear. but where is the sudo chown of chrome-sandbox launched? or the launching of Zypak?

In the manifest, when building the Flatpak the install commands directly set the proper permissions for each file. The chrome-sandbox is not yet included in the manifest since it was not available in Cromite.

Zypak is launched by the bash script:

exec cobalt "$@" --no-default-browser-check

I realise this, but it should not be by default.

Sadly, Flatpak does not allow partial access to /etc.

However, we could simply remove the permission to /etc entirely and users who need it can re-enable it.

technically I don't like it, Having another implementation made not by the chromium team on a component as sensitive as the sandbox does not inspire me with confidence.

Me neither. But since Zypak is widely used for Chromium-based applications on Flatpak. It seemed like the way to go.

I would definitely prefer not having it at all. One less security vulnerability to worry about...

searching I found https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch but I don't know exactly what it is.

It seems to allow Chromium to directly support Flatpak's sandbox in addition to kernel unprivileged user namespaces and SUID. Might be a good option to get rid of Zypak.

I guess the sandbox problem is a big one: what tells me that flatpak's sandbox is better than chromium's?

Flatpak's sandbox would be in addition to Chromium's.

Chromium's sandbox prevents webpages from accessing things they shouldn't.
Flatpak's sandbox prevents Chromium from access things it shouldn't.

It is an additional security layer, not a replacement of Chromium's.

The main advantage for users would be to prevent rogue web extensions from accessing things they shouldn't, like the user's private files.
Since Cromite does not have access to it, the extension would not be able access it either.

syhlx · 2024-05-21T17:24:48Z

searching I found https://github.com/flathub/org.chromium.Chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch but I don't know exactly what it is.

It seems that ungoogled-chromium took the same approach: https://github.com/flathub/io.github.ungoogled_software.ungoogled_chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch

syhlx · 2024-05-21T20:26:20Z

I guess the sandbox problem is a big one: what tells me that flatpak's sandbox is better than chromium's?

Flatpak uses exactly the same kernel backends as Chromium for its own sandbox: unprivileged user namespaces and SUID.

https://github.com/flatpak/flatpak/wiki/User-namespace-requirements

uazo · 2024-05-22T08:00:11Z

It seems that ungoogled-chromium took the same approach: https://github.com/flathub/io.github.ungoogled_software.ungoogled_chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch

in fact, it seems like the best choice. i'm trying to figure out what exactly that patch does.
if it worked and you could use it in cromite, you would no longer need Zypak and chrome_sandbox

uazo · 2024-05-22T08:55:46Z

then, I saw how it works, technically it makes it possible to spawn processes via dbus to the flatpak interface.
there are two things to look into:

https://github.com/flathub/io.github.ungoogled_software.ungoogled_chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch#L616 FlatpakSandbox::GetSandboxLevel
It seems that the signal to understand whether flatpak is active is the presence of the /.flatpak-info file, perhaps it is to see if there is something else that can be exploited, perhaps by accessing some /proc/ directory.
https://github.com/flathub/io.github.ungoogled_software.ungoogled_chromium/blob/master/patches/chromium/flatpak-Add-initial-sandbox-support.patch#L891 some options do not seem to be supported
Since in FlatpakSandbox::SpawnOnBusThread only a few launch_options seem to be supported (clear_environment and kill_on_parent_death) it should be understood what the others are for, and to do this it would be better to remove all other options from the cpp class and wait for compiler errors.
this would make us understand whether there are options used by chromium (without flatpak) that flatpak does not support, and thus understand whether flatpak's sandbox grants fewer guarantees than chromium's (we are talking about renderers).

uazo · 2024-05-22T09:03:51Z

Flatpak's sandbox would be in addition to Chromium's.
Chromium's sandbox prevents webpages from accessing things they shouldn't.
Flatpak's sandbox prevents Chromium from access things it shouldn't.
The main advantage for users would be to prevent rogue web extensions from accessing things they shouldn't, like the user's private files.

which is equivalent to saying that flatpak's sandbox is better than chromium's, since chromium already protects indiscriminate access to resources. which may well be true, I have no basis for saying.

It is an additional security layer, not a replacement of Chromium's.

What I question is that it may not be an additional layer, but something that limits the one already present.

valtoree · 2024-05-25T02:18:30Z

Excited to see this on flathub. Looking forward to it. Well done to everyone helping. Unfortunately I'm not skilled to help. But you have my emotional support. you can do it! ✊

uazo · 2024-05-25T06:52:16Z

I make available here https://github.com/uazo/cromite/releases/tag/flatpak-sandbox-patch the release 125.0.6422.76-79775d5c2adceb3f886b3c023f8b94604b7cd707 rebuilded with the patch in #1149 (sorry, I did it offline :).
what i expect is that, distributed with flatpak, cromite will start directly using flatpak's api without having to use Zypak and chrome_sandbox which must not be present in the package.

I haven't tested it because I don't know how.
If someone can test it or explain to me step by step what I have to do.

uazo · 2024-06-05T07:15:36Z

let me know i can help here.

of course you can.
try the installation using the package in #1053 (comment)

syhlx · 2024-06-05T12:11:36Z

@userforsource

You can post it in flathub as an beta or alpha app. So many users will look into and give feedback.

Or we can publish something clean.

I understand that you are eager to get the Flatpak, but Cromite is focused on security and privacy. I don't think that publishing something half-baked would be the right idea, even as a beta.

In the meantime, if you want to test out the Flatpak and give feedback, you can:

Build the Flatpak yourself here: https://github.com/syhlx/cromite-flatpak
Test uazo's patch here: https://github.com/uazo/cromite/releases/tag/flatpak-sandbox-patch

@uazo

I haven't tested it because I don't know how. If someone can test it or explain to me step by step what I have to do.

I'll test it out and also make the necessary changes to the test repo to accommodate the patched version.

othmahammedi · 2024-06-05T12:44:23Z

Hi, I built the app using the above repository with the Zypac module removed.
The browser is working fine and has been for several days.

I have one question:
The size of the app is large compared to other browsers about 220 megabytes, is it possible to reduce the size?

syhlx · 2024-06-05T12:52:19Z

I can also confirm that everything seems to work as it should.

I updated the test repo to work with the new patched version.

syhlx · 2024-07-01T07:41:22Z

The question of Flatpak is now resolved.

Flatpak poses too many security concerns to be used.

But I need someone to explain to me how to make a repo for apt.
EDIT: in a different issue, possibly

I opened a new issue dedicated to this new discussion of packaging for Linux.

uazo · 2024-07-01T14:31:16Z

#1053 (comment)

it must be considered whether to insert a warning message

syhlx · 2024-07-01T23:52:22Z

#1053 (comment)

it must be considered whether to insert a warning message

Releasing Cromite as a Flatpak with a warning message could be a middle ground to allow users to choose for themselves if they are OK with the risks involved.

Where would you put the warning, though? On the Flathub/Github page or directly in Cromite?

iamgitcat · 2024-07-02T04:40:28Z

Releasing Cromite as a Flatpak with a warning message could be a middle ground to allow users to choose for themselves

As a common user reading this discussion lefts questions about security issues flatpak introduces. It would be good to describe them on github readme, so users could choose the distribution themselves. As a Silverblue user Flatpak is preferred and it also has benefits too, easy to install and manage/update browser and data.

uazo · 2024-07-02T07:16:28Z

On the Flathub/Github page or directly in Cromite?

directly into cromite, if it detects the flatpak sandbox.

It would be good to describe them on github readme,

@iamgitcat you are welcome, go ahead and make a pull

boredsquirrel · 2024-07-05T17:45:34Z

Hey I want to add some comments here

@valtoree your quotes are not really useful.

Brave does not refer to security. They just say "the experience is worse". This may be due to missing drag&drop or "native messaging" needed for some extensions. These are portals being worked on, and will be fixed in the future.

Vivaldi referred to security implications, but they may not be on the latest point of information.

Secureblue is a very opinionated project, and security is a complicated, not black-white topic.

Flatpak Chromium may very well be more secure than non-flatpak Chromium.

it uses BPF to isolate syscalls. This is not changed by Flatpak.
it uses a user namespace sandbox for filesystem sandboxing. This can be replaced with zypak, as the fork server zygote can invoke flatpak-spawn to spawn a subprocess like a tab. This means all processes are separately sandboxed with bubblewrap, a very secure and suid-less sandboxing solution.
the main browser is also sandboxed with bubblewrap, unlike a natively installed Chromium. This includes a seccomp filter which uses badness enumeration and could be more secure but it is way better than nothing.

in short: This is simply "chromiums filesystem sandbox" vs. "bubblewrap filesystem sandbox", additionally to the point that Flatpak Chromium IS sandboxed, while native Chromium is not.

I hope you reconsider your choice. But it is really not transparent, which is why these discussions need to exist.

Btw Flatpak Firefox just relies on seccomp-bpf alone and the devs are fine with that. Not sure if this is a good idea, and FF devs are afaik working on a fork server.

cjao · 2024-08-25T12:09:56Z

Flatpak Chromium may very well be more secure than non-flatpak Chromium.

* it uses BPF to isolate syscalls. This is not changed by Flatpak.

* it uses a user namespace sandbox for filesystem sandboxing. This can be replaced with zypak, as the fork server zygote can invoke `flatpak-spawn` to spawn a subprocess like a tab. This means all processes are separately sandboxed with bubblewrap, a very secure ans suid-less sandboxing solution.

* the main browser is also sandboxed with bubblewrap, unlike a repo natively installed Chromium. This includes a seccomp filter which uses badness enumeration [and could be more secure](https://github.com/flatpak/flatpak/issues/4349) but it is way better than nothing.

I hope you reconsider your choice. But it is really not transparent, which is why these discussions need to exist.

This is all good theory, but @uazo seems to have empirical evidence to the contrary. Flatpak does not merely add a security layer on top Chromium because Chromium does not work out of the box with Flatpak. The Chromium flatpak significantly modifies the Chromium sandbox to adapt it to Flatpak's confinement model.

uazo · 2024-08-26T14:35:40Z

Hopefully it could be submitted upstream someday and get properly scrutinized by some experts.

#1053 (comment) I fully agree

refi64 · 2024-08-27T02:02:00Z

Hello, Chromium Flatpak maintainer here. I think there are a few points in this issue that aren't quite accurate:

do not have the dumpable flag

I don't understand what this is testing? First of all, PR_SET_DUMPABLE is only 0 when using the setuid sandbox. If I run a standard Chromium install normally, then PR_SET_DUMPABLE is never called, which is observable by ls -l /proc/PID as you showed. This isn't a regression in the Flatpak at all.

Now, I also don't understand your test results. In there, I see that the Flatpak Chromium's /proc/PID is owned by root, which would imply that PR_SET_DUMPABLE=0 actually happened successfully? And it's actually the local copy that doesn't have it set? Zypak Flatpaks do have that set, because they're stubbing in the setuid sandbox, so Chromium happily configures the dumpable flag.

The purpose of this is to block the ability to use ptrace, but Flatpak already disables the use of ptrace anyway, so the utility isn't really high.

not being able to access the disk

This check is flawed. Flatpaks run inside of an isolated rootfs, but that rootfs is mounted on top of the existing rootfs. If you actually nsenter / flatpak enter into the binary, you'll see the empty isolated rootfs, only containing the read-only runtime and application files (but not your user data). (You might notice that ~/.var does exist, but the only thing inside there is read-only libwidevinecdm.so, which is necessary because sandboxed processes do need Widevine.)

have a current directory that is not accessible

See the above.

Two more things I'd like to add:

It's true that the individual zygote subprocesses share a PID namespace, as they would under the setuid sandbox, but Flatpak's blocking of ptrace makes it hard to do anything useful with that.
As previously mentioned, the layer 2 sandbox is indeed still active and untouched.

uazo · 2024-08-27T07:26:18Z

Flatpak already disables the use of ptrace anyway, so the utility isn't really high.

do you have any way of telling me how to test it in the field?

Flatpaks run inside of an isolated rootfs

so you are telling me that different (render) processes do not share the same folder and that that folder is not the same as the browser process?

robertwthomson · 2024-08-27T08:39:36Z

do you have any way of telling me how to test it in the field?

Hi, I am just a lurker watching this. Since I actually do know how to test this I figured I would create an account and answer. Chromium actually uses ptrace for creating crashdumps. Because Chromium under flatpak does not have access to ptrace, it cannot create crashdump files. So this actually provides a way you can confirm that ptrace is not available to Chromium.

If you launch org.chromium.Chromium from flathub and load chrome://crash (a test URL for generating a crashdump), then have a look in the "Crash Reports" folder you will find nothing.

find ~/.var/app/org.chromium.Chromium/config/chromium/Crash\ Reports -name '*.dmp'

However, if you launch org.chromium.Chromium again with --allow=devel (a non default option that does permit ptrace) and then go to chrome://crash, you will find a crash dump file is indeed generated.

flatpak run --allow=devel org.chromium.Chromium

uazo · 2024-08-27T09:04:32Z

Because Chromium under flatpak does not have access to ptrace, it cannot create crashdump files.

and concerning the same process? is allowed to ptrace itself?

robertwthomson · 2024-08-27T09:28:03Z

and concerning the same process? is allowed to ptrace itself?

I don't think so. I thought of another way to test this.

$ flatpak run --user --command=bash org.freedesktop.Sdk//23.08
$ pidof bash
2
$ /usr/bin/strace -p 2
/usr/bin/strace: test_ptrace_get_syscall_info: PTRACE_TRACEME: Operation not permitted
/usr/bin/strace: attach: ptrace(PTRACE_ATTACH, 2): Operation not permitted

robertwthomson · 2024-08-27T09:47:37Z

Ok, I realised that I was not testing a process ptracing itself. And in fact I am not sure how to easily test that because the strace command itself does not want to trace itself and errors if you try

$ flatpak run --user --command=/usr/bin/strace org.freedesktop.Sdk//23.08 -p 2
/usr/bin/strace: I'm sorry, I can't let you do that, Dave.

Cool, error message from strace though. 🙂

Ultimately I think someone who knows flatpak better than me would have to answer but my understanding is that ptrace is not possible at all in a flatpak environment by default, outside of enabling devel (edit, @Erick555 beat me to it and confirms below).

Erick555 · 2024-08-27T10:15:34Z

and concerning the same process? is allowed to ptrace itself?

whole ptrace syscall is blocked by default

Erick555 · 2024-08-27T10:19:28Z

This isn't necessarily good thing for chromium as crash reports are useful. For this reason mozilla does enable ptrace for firefox flatpak.

robertwthomson · 2024-09-02T12:36:40Z

Flatpaks run inside of an isolated rootfs

so you are telling me that different (render) processes do not share the same folder and that that folder is not the same as the browser process?

Something you can answer @refi64? Or any thoughts at least? How does this compare with say the SUID sandbox? Do you know?

boredsquirrel · 2024-09-15T20:52:06Z

btw just noticed, even though the package name is already changed, the correct github name would be io.github.author.project according to the docs

syhlx changed the title ~~Building a Flatpak for Linux~~ Creating a Flatpak for Linux May 1, 2024

uazo added the need triage I will look into it, I promise! label May 3, 2024

uazo added a commit that referenced this issue May 21, 2024

Update build_cromite.yaml

754f4cb

#1053 add chrome_sandbox

uazo mentioned this issue May 21, 2024

Add chrome-sandbox to the Linux x86_64 release workflow #1121

Closed

6 tasks

uazo mentioned this issue May 25, 2024

Add support to flatpak sandbox: test feature #1149

Draft

6 tasks

olumolu mentioned this issue May 25, 2024

cromite in flathub flathub/flathub#5284

Closed

syhlx mentioned this issue Jul 1, 2024

Packaging for Linux #1259

Open

syhlx closed this as not planned Won't fix, can't repro, duplicate, stale Jul 1, 2024

uazo reopened this Jul 1, 2024

uazo added need triage I will look into it, I promise! and removed working on it working on it labels Jul 1, 2024

user1-github mentioned this issue Jul 17, 2024

Upstream the Flatpak sandbox code flathub/org.chromium.Chromium#337

Open

olumolu mentioned this issue Jul 26, 2024

[Feature request]: application can't be ported to flatpak as this is less secure?is not secure as per the app dev why not fix this issue flatpak/flatpak#5879

Closed

2 tasks

sricks mentioned this issue Aug 5, 2024

Clarifications regarding Brave FlatPak sandboxing state and Fedora Silverblue official install guide brave/brave-browser#36457

Closed

cjao mentioned this issue Aug 25, 2024

[Feature request]: Support applications with internal sandboxes flatpak/flatpak#5921

Open

2 tasks

uazo mentioned this issue Oct 23, 2024

Auto update on Linux #771

Open

5 tasks

nihil-admirari mentioned this issue Nov 12, 2024

Investigate and document directly sandboxing chromium with bubblewrap, including effects on the chromium internal sandbox secureblue/secureblue#507

Open

uazo mentioned this issue Nov 24, 2024

AppImage Needed, Build Script Provided. #1579

Open

4 tasks

Creating a Flatpak for Linux #1053

Creating a Flatpak for Linux #1053

Comments

syhlx commented May 1, 2024

uazo commented May 1, 2024

syhlx commented May 1, 2024

uazo commented May 1, 2024

syhlx commented May 1, 2024

uazo commented May 3, 2024

syhlx commented May 4, 2024

AlphaElwedritsch commented May 17, 2024

olumolu commented May 19, 2024

uazo commented May 21, 2024

uazo commented May 21, 2024

syhlx commented May 21, 2024 • edited Loading

uazo commented May 21, 2024

syhlx commented May 21, 2024 • edited Loading

syhlx commented May 21, 2024

syhlx commented May 21, 2024

uazo commented May 22, 2024 • edited Loading

uazo commented May 22, 2024

uazo commented May 22, 2024

valtoree commented May 25, 2024

uazo commented May 25, 2024

uazo commented Jun 5, 2024

syhlx commented Jun 5, 2024 • edited Loading

othmahammedi commented Jun 5, 2024

syhlx commented Jun 5, 2024

syhlx commented Jul 1, 2024 • edited Loading

uazo commented Jul 1, 2024

syhlx commented Jul 1, 2024

iamgitcat commented Jul 2, 2024

uazo commented Jul 2, 2024

boredsquirrel commented Jul 5, 2024 • edited Loading

cjao commented Aug 25, 2024

uazo commented Aug 26, 2024

refi64 commented Aug 27, 2024

uazo commented Aug 27, 2024

robertwthomson commented Aug 27, 2024 • edited Loading

uazo commented Aug 27, 2024

robertwthomson commented Aug 27, 2024

robertwthomson commented Aug 27, 2024 • edited Loading

Erick555 commented Aug 27, 2024

Erick555 commented Aug 27, 2024

robertwthomson commented Sep 2, 2024 • edited Loading

boredsquirrel commented Sep 15, 2024

syhlx commented May 21, 2024 •

edited

Loading

syhlx commented May 21, 2024 •

edited

Loading

uazo commented May 22, 2024 •

edited

Loading

syhlx commented Jun 5, 2024 •

edited

Loading

syhlx commented Jul 1, 2024 •

edited

Loading

boredsquirrel commented Jul 5, 2024 •

edited

Loading

robertwthomson commented Aug 27, 2024 •

edited

Loading

robertwthomson commented Aug 27, 2024 •

edited

Loading

robertwthomson commented Sep 2, 2024 •

edited

Loading