AppImage sandboxing issues on linux-hardened kernel

[RazorEdge]

Hey all,

I'm running the linux-hardened kernel on Arch and am generally a very security-focused user. I'm having an issue with AppImages (Bitwarden and Tuta specifically). When I attempt to execute either AppImage, I get this error:

[15998:0719/151223.182709:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:163] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_BitwarKOal6N/chrome-sandbox is owned by root and has mode 4755.

I'm aware I can work around the issue by using the --no-sandbox option or changing the ownership/permissions on the /tmp/.mount_AppImage/chrome-sandbox. However I'm concerned about the security implications of both of these and I don't fully understand all the moving parts.

If I run:

zcat /proc/config.gz | grep CONFIG_USER_NS

I get:

CONFIG_USER_NS=y
# CONFIG_USER_NS_UNPRIVILEGED is not set

I believe this means unprivileged user namespaces are disabled, and to run these AppImages, they need to be enabled? Is there any way to run these without weakening the security model? The reason I'm interested in the Bitwarden AppImage is the Arch repository version of Bitwarden is typically a few versions behind. But I'd rather run that over opening up a privilege escalation vector.

Is anyone able to provide an analysis of the best way forward here? I'm aware this threat model is likely beyond my requirements, but I find it interesting. Thanks

 

[Trml]

I'm not sure

# CONFIG_USER_NS_UNPRIVILEGED is not set

is the cuprit with that error. You can test it easily by booting the regular Arch kernel, which has the setting, but that's obviously no general replacement for the hardened kernel. The most regular software that gets broken by that missing config are (chromium/firefox-based) browser built-in sandboxes. With chromium you just don't see it breaking, because it comes with SUID-bit set for it.
I have no experience using either bitwarden or tuta, I guess they are both pretty security aware development companies, which might make a decision to disable the sandbox easier. Personally I'd happily rely on regular repo packages for the productive system generally, because appimages are a wildcard and I'd rather have the distro ensure the apps function as expected and don't obtain more privileges than needed (if not with release x.x, perhaps with x.y).
Furhter, you might consider what else you run on the system and how you use the apps (e.g. do they stay open when you suspend it, do other stuff that may go wrong/enable an avenue to your data of said apps, etc) but I guess that part applies when you run the regular packages instead too. If the system is running unsupervised, perhaps with networked services in the background, it's a different risk profile than you opening bitwarden to get your password for tuta login and closing it again. A password manager or email inbox are good examples of personal data that whatever rogue app may be seeking. To sum it up: consider how your data is sandboxed first and only next how much you need the latest (appimage) features and how to daily use those safely.

 

[RazorEdge]

Thanks for the input @Trml. I think I'll probably just run the web Tuta and Arch-repo Bitwarden versions for now as I can't see a simple way to work around this without enabling unprivileged user namespaces - the security tradeoff doesn't feel worth it. I'm interested in any other perspectives though

 

[Trml]

That reads like a sound approach to me, @RazorEdge . For more background info, there is an older bug report for the linux.hardened kernel extensively discussing to enable unprivileged user namespaces in config, or not. In short they did not enable it, because there have been plenty cve with the sandboxing feature in the past, i.e. it was seen better on paper than practise. Unfortunately, software devs have to decide which security design path to follow. Hence, it remains a rather intricate process to find the best preset compromise for ones own user data/usecase.