Flatpak support on testing branch

Continuing the discussion from: Does anyone actually use snaps?

May I ask if this ISO's are build against stable, or is the problem with the user namespaces solved which affects Flatpak among other things?

testing

I am not familiar with that issue, how can I test it?

1 Like

Install and run a flatpak application, the result in my case on unstable is this:

bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.

The issue still exists.

Is it a hard requirement of flatpak now?

Last time enabling unprivileged user namespaces came up it seemed like the consensus was it was fundamentally insecure.

No this issue has been introduced with snapd/apparmor support recently, it also affects different gnome components which don't work now as expected.


For me this is a critical game stopper right now. So I hope it gets more attention before any new ISO's are released!

It isn't related to the recent work made by Philm to implement Snapd. Arch Linux also got affected by this issue on its zen kernel. It merely happened coincidentally.

The root cause of that is that because Arch changed a compile option for BubbleWrap staring with bubblewrap 0.3.3-2. Instead of using --with-priv-mode=setuid like in bubblewrap <= 0.3.3-1, it now use --with-priv-mode=none.

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/bubblewrap&id=bf828975d4cf5654af7fabe0452e323636191748

https://bugs.archlinux.org/task/62990
https://bugs.archlinux.org/task/62985
https://bugs.archlinux.org/task/62982

EDIT: Added the explanation I found by looking at some tickets.

7 Likes

This is good news I guess :wink: Thanks for clarifying !

It looks like downgrading bubblewrap resolves the issue if you need a temp workaround.

1 Like

I just downgraded bubblewrap and can confirm that it solves this issue!

See above for why downgrading works.

Although instead of downgrading, a more viable fix in long term would be to set the kernel variable to 1, as mentioned in the error message.

I don't know if Manjaro Team will make the change at compile time to make this value the default one on Manjaro kernels, or if Manjaro will simply let users do the job themselves.

I think it would be a bad decision to keep it that way, also from your provided links I see this:

Comment by vasya (vasya) - Monday, 24 June 2019, 06:43 GMT

This is because the package changed to be non-SUID in the latest versions. It should, however, be SUID, and it was SUID in previous versions. Reversion of this change is required.

You can see that bubblewrap is intended to be SUID by checking e.g. it's README:

So i will keep some hope that upstream reverts their decision.

Except, if that introduces security issues, I think it would be better to rebuild bubblewrap as setuid again.

This is nautilus Arch Testing as you see with the correct kernel being 5.1.15-arch1-arch all is fine is Manjaro using arch linux zen kernel I was under the impression Manjaro rolled its own

No idea which option (setting this kernel parameter at 1 by default VS compile BubbleWrap with --with-priv-mode=setuid) would actually be the best in term of security.

At first glance, I would agree with you since changing a default value for a kernel parameter can potentially impact way more users (thus make way more people vulnerable) than changing a compile option for BubbleWrap since on Manjaro, nearly everyone use a kernel provided by Manjaro while way less people on Manjaro actually use BubbleWrap (directly or indirectly).

But compiling BubbleWrap with --with-priv-mode=setuid would mean that Manjaro Team would have yet another package to maintain in addition to everything else. It is starting to cumulate quite a lot, and at one point, it could become unsubstainable if Manjaro Team doesn't grow in term of workforce.

Also, on Arch Linux, they decided to enable that feature by default (and did so by changing the compile configuration). So it might be not that much of a big deal for them now.

https://bbs.archlinux.org/viewtopic.php?id=247016
https://git.archlinux.org/linux.git/commit/?h=v5.1.8-arch1&id=d279aeda16b4cc525a0a2c4747946d87683e3e51

(The Arch Wiki says " However, due to more general security concerns, the default Arch kernel does ship with User Namespaces enabled only for the root user.", the second part being now false with the change mentioned above. Unfortunately, if doesn't detail what "more general security concerns" actually are, so it is hard to evaluate if it is really a big deal or not with just that documentation.

Source: https://wiki.archlinux.org/index.php/Linux_Containers#Enable_support_to_run_unprivileged_containers_(optional)

EDIT July 2nd 2019: The article on Arch Linux wiki got fixed. They changed "default Arch kernel" for "linux-hardened kernel", which is accurate with the current situation.)

No, Manjaro doesn't use linux-zen from Arch. It is compiling its own kernels.

But as I mentioned above, Arch Linux changed the default value for unprivileged_userns_clone kernel parameter to 1/yes/etc. for its kernel (except maybe linux-hardened, although I would need confirmation, but I would not be surprised since obviously, it is a hardened kernel.).

But Manjaro did not make the same change, and I don't know if they will actually do the change or not.

1 Like

Well....one would impact a percentage of users and the other would impact every user of every Manjaro system. Also, those users who wish to disable user namespaces would then also need to maintain manual builds of bubblewrap

even more strange i use the cooking vanilla kernel and thumbnails are fine here.
I was jesting about Manjaro using Arch kernels mind you.

This is the current difference of the config:

--- config.x86_64	2019-06-10 09:02:38.384917514 +0200
+++ config-arch	2019-07-01 06:51:19.418312725 +0200
@@ -1,13 +1,13 @@
 #
 # Automatically generated file; DO NOT EDIT.
-# Linux/x86 5.1.9-1 Kernel Configuration
+# Linux/x86 5.1.14-arch1 Kernel Configuration
 #
 
 #
-# Compiler: gcc (GCC) 8.3.0
+# Compiler: gcc (GCC) 9.1.0
 #
 CONFIG_CC_IS_GCC=y
-CONFIG_GCC_VERSION=80300
+CONFIG_GCC_VERSION=90100
 CONFIG_CLANG_VERSION=0
 CONFIG_CC_HAS_ASM_GOTO=y
 CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
@@ -20,8 +20,8 @@ CONFIG_THREAD_INFO_IN_TASK=y
 #
 CONFIG_INIT_ENV_ARG_LIMIT=32
 # CONFIG_COMPILE_TEST is not set
-CONFIG_LOCALVERSION="-MANJARO"
-# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
 CONFIG_BUILD_SALT=""
 CONFIG_HAVE_KERNEL_GZIP=y
 CONFIG_HAVE_KERNEL_BZIP2=y
@@ -35,7 +35,7 @@ CONFIG_HAVE_KERNEL_LZ4=y
 CONFIG_KERNEL_XZ=y
 # CONFIG_KERNEL_LZO is not set
 # CONFIG_KERNEL_LZ4 is not set
-CONFIG_DEFAULT_HOSTNAME="manjaro"
+CONFIG_DEFAULT_HOSTNAME="archlinux"
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 CONFIG_SYSVIPC_SYSCTL=y
@@ -167,6 +167,7 @@ CONFIG_NAMESPACES=y
 CONFIG_UTS_NS=y
 CONFIG_IPC_NS=y
 CONFIG_USER_NS=y
+CONFIG_USER_NS_UNPRIVILEGED=y
 CONFIG_PID_NS=y
 CONFIG_NET_NS=y
 CONFIG_CHECKPOINT_RESTORE=y
@@ -625,7 +626,7 @@ CONFIG_AMD_NB=y
 # Binary Emulations
 #
 CONFIG_IA32_EMULATION=y
-CONFIG_X86_X32=y
+# CONFIG_X86_X32 is not set
 CONFIG_COMPAT_32=y
 CONFIG_COMPAT=y
 CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
@@ -807,7 +808,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_FORCE_LOAD=y
 CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
+# CONFIG_MODVERSIONS is not set
 CONFIG_MODULE_SRCVERSION_ALL=y
 CONFIG_MODULE_SIG=y
 # CONFIG_MODULE_SIG_FORCE is not set
@@ -6292,7 +6293,6 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER=y
-CONFIG_BOOTSPLASH=y
 # CONFIG_LOGO is not set
 CONFIG_SOUND=m
 CONFIG_SOUND_OSS_CORE=y
@@ -9295,7 +9295,7 @@ CONFIG_BIG_KEYS=y
 CONFIG_TRUSTED_KEYS=m
 CONFIG_ENCRYPTED_KEYS=m
 CONFIG_KEY_DH_OPERATIONS=y
-CONFIG_SECURITY_DMESG_RESTRICT=y
+# CONFIG_SECURITY_DMESG_RESTRICT is not set
 CONFIG_SECURITY=y
 CONFIG_SECURITYFS=y
 CONFIG_SECURITY_NETWORK=y
@@ -9333,18 +9333,14 @@ CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
 # CONFIG_SECURITY_APPARMOR_DEBUG is not set
 # CONFIG_SECURITY_LOADPIN is not set
 CONFIG_SECURITY_YAMA=y
-# CONFIG_SECURITY_SAFESETID is not set
-CONFIG_INTEGRITY=y
-# CONFIG_INTEGRITY_SIGNATURE is not set
-CONFIG_INTEGRITY_AUDIT=y
-# CONFIG_IMA is not set
-# CONFIG_EVM is not set
+CONFIG_SECURITY_SAFESETID=y
+# CONFIG_INTEGRITY is not set
 # CONFIG_DEFAULT_SECURITY_SELINUX is not set
 # CONFIG_DEFAULT_SECURITY_SMACK is not set
 # CONFIG_DEFAULT_SECURITY_TOMOYO is not set
 # CONFIG_DEFAULT_SECURITY_APPARMOR is not set
 CONFIG_DEFAULT_SECURITY_DAC=y
-CONFIG_LSM="yama,loadpin,safesetid,integrity"
+CONFIG_LSM="yama"
 CONFIG_XOR_BLOCKS=m
 CONFIG_ASYNC_CORE=m
 CONFIG_ASYNC_MEMCPY=m

I'll do a research on how and why it got changed.

I really like the mindset here: If bwrap is setuid, glibc will sanitize its environment. This makes it impossible to pass e.g. TMPDIR into the sandbox without a helper script on the other side.

Currently I reverted the bwrap changes. Will see if other distributions have some patches for flatpak.

2 Likes

Can you retest again?