I’ve been working on a snap for percollate. This is a node-based commandline app which converts websites into pretty pdf or epub files. It renders these through puppeteer (Chrome) via Mozilla’s Firefox Reader View. My intention is to pass this package upstream when it is ready.
The upstream package uses the Chrome sandbox by default. Running the snap under strict confinement without plugs or plugging browser-support causes a segfault. Possible solutions to this are:
Set the command to percollate --no-sandbox by default.
After discussion with @cjp256 at the snapcrafters VC on Friday, he recommended toggling on allow-sandbox: true to the browser-support plug. This builds a functional snap which does not require --no-sandbox but gets rejected from store upload.
What is the best way to go forward with this? It seems counterintuitive to disable Chrome’s sandboxing in the interests of “security”. Which option is safest? Could I reassure upstream that automatically passing --no-sandox is a sensible approach? If the second approach is best, can I request permission for this app, please?
Thanks ogra. Are they exactly equivalent, though? Is there a comparison document I can present to upstream to prove this? This is, after all, an application which will be pointed at arbitrary websites and will be exposed to all kinds of nastiness. It’ll have access to the home plug so a malicious exploit could cause a lot of damage.
i dont think they are equivalent, snapd uses in-kearnel features heavily (apparmor, seccomp, namespaces, cgroups, etc) that make sure nothing can break out of the secure environment.
the app itself will never have such a grade of power to use kernel level features that low so i’d expect the app sandbox to be on a different (weaker) level … snapd runs as root, wraps the app and sets the security features up as root while a standalone app runs as the user and can only operate in this context when spawning its sandbox features.
if you hit a vulnerability that allows a site to access the system in an unallowed way, the access will end up in the snap sandbox, not on the actual host …
if users are paranoid they can indeed turn off the home interface and simply use the app via the app specific home in ~/snap that snapd creates for each app …
Thanks again, ogra. For the purposes of a commandline web browser and pdf generator, I think the priority is to protect the user from ransomware attacks whilst maintaining usability. As such, I don’t think strict confinement with home unplugged is a viable option. I’m presuming the Chrome sandbox offers more than snapd does for this usecase (hence why this interface exists in the first place)?
As @ogra said above, the snap sandbox comprises multiple layers of protection (seccomp, apparmor and namespaces to name a few) whilst as far as I understand, the chromium sandbox is only seccomp - so the snap sandbox should be more strict and a better option in my opinion.
Thanks Alex. I appreciate the multiple layers argument. But are those layers protecting what needs protected?
As a user, I want to be able to open a terminal, type percollate epub https://whateversite.com, have the file download and expect to be safe from a piece of ransomware encrypting my home folder. From what I can tell:
If the application is run under strict confinement with home not plugged, I’m safe from attack but I cannot run the app/download into my home folder. I’d have to navigate to a subdirectory under ~/snap/percollate, which is user-hostile.
If the application is run under devmode confinement (or strict with the allow-sandbox flag passed to the browser-support plug and home plugged as well) with the Chrome sandbox active, the application functions as required and the Chrome sandbox prevents an unsophisticated piece of malware being able to access my home folder. I’d miss out on additional layers of security, but the things which are important to me - as a user - are somewhat protected and the user experience is good.
If the application is run under strict confinement and home is plugged, I cannot use the Chrome sandbox without the additional plug requirement in the OP. I can run the application from any directory, but I have no protection whatsoever against unsophisticated malware attempting to encrypt my home folder.
To my mind, option 2 is far superior to 1 or 3. Of course, this assumes the Chrome sandbox on Linux actually prevents the Chrome processes from accessing arbitrary files on the user’s machine. I can’t find any documentation - beyond a cartoon in the Google documentation - which says that is the case. However, I assume that is why the browser-support plug has the allow-sandbox flag in the first place?
