Snapcraft

should not remove suid/guid from binaries when confinement is devmode

Bug #1599234 reported by Olivier Tilloy
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Snapcraft
New
Undecided
Unassigned

Bug Description

Use case: I’m building a snap for webbrowser-app, which embeds oxide (https://launchpad.net/oxide). When snapcraft creates the package, I’m seeing this:

Removing suid/guid from /build/webbrowser-app/snap/parts/webbrowser-app/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox

This effectively prevents oxide from functioning correctly:

[0705/173002:FATAL:setuid_sandbox_host.cc(162)] 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 /snap/webbrowser-app/x1/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox is owned by root and has mode 4755.

While the issue will need to be addressed properly, I think that when building the snap in devmode, snapcraft shouldn’t remove the suid/guid from the binary, as it would be useful for testing the resulting package unconfined.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thank you for filing a bug. I think this is the wrong way to handle this with the current implementation since snaps are created with -all-root and therefore any suid/sgid files would automatically be root. An implementation that supports suid/sgid unconditionally in snaps that worked meaningfully for the snaps would need very careful design.

I think the proper solution would be to not use the setuid sandbox but instead use the userns sandbox once it is supported (bug #1586547). Using the userns sandbox will allow the snap to work in devmode today. To make the snap work in strict mode today (ie, while 1586547 remains open), you can disable the chromium sandbox and rely on snapd's security policy.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Thanks for the detailed explanations Jamie. For the time being, running oxide without the chromium sandbox (by setting the OXIDE_NO_SANDBOX environment variable to 1) does the trick. In the future, I’ll look into using the userns sandbox.

Revision history for this message
Olivier Tilloy (osomon) wrote :

What is needed now to re-enable the sandbox in the webbrowser-app snap is to make oxide support the userns sandbox (that’s bug #1447345).

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

You can also use 'allow-sandbox: true' in the browser-support interface to use the setuid sandbox in webbrowser-app. snapcraft is correctly stripping this, but you can unsquash, reset these bits and then run 'snapcraft snap ./squashfs-root' to recreate your snap.

This is not ideal and the userns sandbox is preferred, but it can be used to unblock yourself for now.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

We discussed this in a meeting recently, but I think it would be useful if there was an oxide snapcraft part that automatically set OXIDE_NO_SANDBOX=1 when using oxide as a webview. We are getting more and more oxide snaps in the store and they are not using this and requesting the reserved 'allow-sandbox: true'.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Agreed. See bug #1651166 for tracking that in oxide.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.