We would like our 1Passowrd Snap to be added to the allowlist for the browser-support interface to be able to set the attribute allow-sandbox: true.
We enable the seccomp-based sandbox provided by Chromium in our other package formats and wish to enforce the best possible security in our Snap as well.
Thanks for the consideration.
Historically, the use of allow-sandbox: true has been reserved for actual web browsers, whilst for electron apps we suggest to disable the chromium sandbox since strict confinement provides a more comprehensive, defense in-depth approach by using both seccomp plus AppArmor, device cgroups etc to restrict what a snap can access.
However, we have granted this previously for vetted publishers so it is not out of the question. As such, given 1password is already a trusted publisher, this could be done. But I would like to understand more whether you feel the standard snap confinement is insufficient and hence why the need for the chromium sandbox - since to use the chromium sandbox, we essentially open up the snap sandbox confinement to allow the various system-calls and accesses etc which are needed to configure the chromium sandbox and as such this weakens the snap confinement and then relies more heavily on the chromium sandbox to ensure confinement. Thanks.
Thanks @alexmurray. We have no concerns about the about the security of Snap confinement, and I think the Snap team is doing incredible things for secure app deployment on Linux.
This ask comes from two places: first, our app is available in several package formats, and we want to be able to reason about its baseline security design in a way that’s as simple and consistent as possible across distributions. Disabling the Chromium sandbox for the Snap build gives us more variations in behaviour and a larger surface area to understand and protect.
Secondly, we are not too concerned about the security of the main process. Snap confinement and AppArmor are a great help there. But we want to do everything we can to harden the renderer processes with web content, and we believe the Chromium team is in a unique position to assist here since they understand exactly what their platform needs. Doubling up on sandbox tech with different focuses seems preferable to us to disabling any of them.
Thanks for the detailed explanation, this makes a lot of sense when viewed from that context. Whilst allow-sandbox does widen the snap confinement to include additional permissions, this still provides some extra level of confinement for additional defense-in-depth.
+1 from me for allow-sandbox: true for the browser-support interface for 1password.
@1password thanks for the detailed explanation. I am then +1 as well for the use of the allow-sandbox: true attribute of the browser-support interface to 1password.
@Igor since this requires publisher vetting, could you please ack this grant?
+1 from me as well, 1password is a verified publisher.
+3 votes for, 0 votes against, granting auto-connect of browser-support to 1password. This is now live.
