Sandboxing / Firejail
ehdis opened this issue · comments
Just out of curiosity. What hurdles prevent support for sailjail? The shared key/location? The different app data directories? Thx.
At least the key shared by all foil apps and I didn't dig deeper than that, because that's enough.
And generally, I don't like the idea of doing something that makes no sense. Sandboxing a trusted app (the app which you trust to encrypt your sensitive data is trusted by definition, right?) makes no sense to me.
Thanks. I feared it that this sharing would stop the harbour version. I saw a whitelist option of sailjail but that would need a application profile under /etc (an option for the chum version maybe). A complete different approach would be a new key location, under ~/.local/share/{OrganizationName}/ but that would need the adaption from Jolla to also mount the
$(dirname ~/.local/share/{OrganizationName}/{ApplicationName}/) inside the sandbox. So, just some thoughts ...
About your general argument. I would take a further step back. A flaw in the OS or a library (ldd /usr/bin/harbour-foilauth) could be used in conjuction with any foil application to compromise the OS or the application. Analogous to an email from a trusted friend but not send from your friend ... . So, an approach to limit the impact is generally a good thing. BTW, as you wrote about trusted apps; is there any attempt (in chum, harbour or here) to sign the rpm packages? That would allow ... you known it.
Have a nice day.
Yeah, it can be argued both ways. And I'm not so much against isolation as such. I would actually vote for sandboxing the browser and possibly the email client/backend - those pull a lot of content from the network which you don't control and which can contain whatever. And possibly the apps which the user doesn't trust (perhaps all of them by default but with an option to mark the app as trusted).
Every instance of a sandbox eats its share of cpu, memory and other resources - it better be worth the trouble (in case of browser and email that overhead would be negligible). Making the system too complex in an effort to make it more secure could actually make the security situation even worse (by introducing new bugs and vulnerabilities). And so on... You have to take all that into account when weighing the pros against cons.
There are also backward compatibility issues - I want my apps to be compatible with as wide range of Sailfish OS releases as reasonably possible. And anything that would break compatibility with Sailfish OS 4.0 which I use on my daily phone (and not planning to upgrade it any time soon) is a non-starter 🙂
And yes, it would be so nice to build and sign rpms on the jolla store/chum side + publish the sources for each build in an easy to review form and build a protection system based on that. But it requires an infrastructure, money, and some full-time people to make it actually work, which isn't realistically possibly these days. I was hoping that Jolla would become the driving force behind such an effort and even tried to propose something like that but it doesn't seem to be happening, unfortunately.