Define, implement and test a proper SailJail "profile" (plus evaluate its necessity) #236
Comments
Olf0
added
enhancement
|
Q: Which branch to submit the SailJail stuff to? Q: Which "Organisation" name to pick? |
|
I would suggest a new branch since < 4.4 and it's 'optional' up to 4.4. Or in sfos4.2 branch: storeman is obviously always going to require rights outside of the normal confines of the jail. Sorry I can't help much currently. Thanks! |
I'm partial to 'real' domains since this is a continuation of java like namespaces. Perhaps a github page and use that domain? io.github.storeman-developer or the like? |
Disregard that. Sailjail 4.2 branch, Sandboxing disabled for the time being accomplishes that the app can be used with >4.3. |
If only you would read, before you write:
So much futile chatter. 😒 This issue has the goal to »Define, implement and test a proper SailJail "profile"«.
Actually I was hoping that you might take care about this issue, because it is not temporally critical and it provides lot of synergy with your other projects for SailfishOS. |
Do you really think that is worth the effort, to achieve I would rather evaluate if it is feasible to call the "Org" P.S.: Another, very similar option discovered by rinigus seems to be https://forum.sailfishos.org/t/migrating-configuration-and-data-files-for-sandboxed-apps/8866/37 |
|
For now I will merge #235 to the But for a proper SailJail configuration, it looks like an new Additionally the new sharing API (once again) in SFOS 4.4.0 https://forum.sailfishos.org/t/sailjail-how-will-it-work-with-sharing-plugins/8655/16 / sailfishos/transfer-engine#6 requires a |
|
I took a cursory look at this. |
- registering dbus service succeeds with this. Contributes-To: storeman-developers#236 Contributes-To: storeman-developers#236
Does that mean "leave it as it is", with I am afraid that Jolla plans to make Sandboxing mandatory in the long run. |
|
Yes. I have heard nothing to that effect. It wouldn't make sense. |
Currently and for a while, that is sure fine & was my plan.
Me neither, but …
exactly the contrary, IMO: What sense does a confinement make, if it is optional and any app author can switch it off for her / his apps? SailfishOS is positioned by Jolla as a "secure" and "privacy enhancing", mobile OS alternative, but on Android and iOS such measures are enforced for long, hence they are much more "secure" and "privacy enhancing" in this regard. I would appreciate very much, if you ask Jolla (at FSO or an IRC community meeting) what their ultimate goal for SailJail is: To enforce it or to keep it optional forever.
Sailors have been quite positive when missing (or too coarse) SailJail permissions have been indicated by app developers and already promised to adopt / adapt a few. Hence this might be something to ask for, too. In addition to Storeman, the SailfishOS:Chum GUI application and other GUI RPM-management tools may utilise an "package management" permission, which allows for accessing |
|
Confinement makes good sense even when you have only most apps confined IMO, and if you are Harbour-only you can know that's all of them. "Untrusted apps" is not such a first class citizen that it must necessarily have all the privileges and responsibilities. Honestly i still barely use OpenRepos at all. I see it has having to strike a compromise between being real Linux in the pocket, and "hardened", and believe the current level is close to the at least an interim goal. Ideally user should be alerted to when an app is not sandboxed though...
I'll see what i can do... i guess the spin here should be if users will start getting alerted to apps having opted out of sandboxing which is genuinely useful. |
IMO not really, because a single "bad" app can access all privacy relevant data on a device or may disturb other apps: Both aspects are addressed by confining apps.
This may be a strategy Jolla has in mind.
Jolla always has been very reluctant to reveal any long-term plans, because they may (have to) decide to alter them. IMO you are over-interpreting the lack of information.
Luckily not really, because as root at the command line, "anything goes". Hence one still "owns" a SailfishOS device and is able to be in full control of a SailfishOS installation, in contrast to stock-Android and iOS.
The current state is always close to some interim goal. 😜 And then the next "interim goal" is set, and so on. This is how engineering of large projects works.
This may be something Jolla considers or already plans. And something I am concerned about. Because I do not want users to be alerted when installing Storeman, because that would be detrimental for OpenRepos and all the SalfishOS software hosted there.
Thank you!
Well, it is Jolla, so it might make sense to design a question not being evaded so easily. Your first take can be easily dismissed by a "No, not currently" without providing any information. This is why my first take offers two options, which are the extremes; IMO it does make sense to add your question as a third option and design a first sentence providing context. Can you think of aspects not covered and possible "easy ways out", besides "We don't know, yet"? Do you thing the question is overloaded and we should drop the "Jolla Store" aspect of it? |
Well, the most sensitive data (e.g. accounts) is already protected from regular non-sandboxed apps.
Whereas I think that is perfectly fine. That question should be good enough to add to the community meeting (and now would be the time to). I probably won't be able to make the next one though, so i have added a reminder for $AFTER_VACATIONS to do something about this if it hasn't already happened. |
Contributes-To: storeman-developers#236
Contributes-To: storeman-developers#236
Contributes-To: storeman-developers#236 This is a combination of 11 commits. update spec: extra package fix .desktop override installation add subdir to pro spec cleanup add Documents permission ... for the Backup functionality use no Orga/App names at all... add PackageKit system permission expand PackageKit dbus permissions randomly fix up the rules ... but we can read ssu finally!! some more cleanups
|
Fooled around a bit:
I guess that is as far as I can take it. This adds a subpackage called There's a lot going on inside Storeman so I am sure there are some things missing in the sailjail config. Most notably, Then there's the case of |
If "at launch" means "when then user starts Storeman", this may be O.K. for a start.
Cool, kudos to you! |
Olf0
changed the title
Yeah, launch is sandbox launch, so every time. |
|
Another thing: the user is now prompted for any "super user" actions (like refreshing repos) with the usual authorization popup. And IIRC this is new behaviour which is not present in a EDIT: I notice the popup when installing or updateing an app is talking about "this softwre is not from a trusted source, superuser auth required". Perhaps the jailed Storeman can not read the developermode/allow untrusted sources setting. |
Although it is not a beautiful solution, I see no issue in carefully loosening polkit rules; i.e., slightly loosening very specific rules for a specific Unix group.
Just to check if I understood the gist of this part correctly: "The superuser-auth pop-up may not be suppress-able via polkit rules" is what it means right? |
I'm not familiar enough with the Sailfish OS authentication system, or polkit, to answer that . There's D-Bus and PackageKit and libzypp and ssu and dsme involved (or maybe one of them isn't...). But yes, if you or someone can cook up a reasonable ruleset to overcome these annoyances that would probably be helpful. And from the looks of it, the one from Storeman-Installer might just be enough as-is. My preferred solution would be for the app to trigger the popup "TOFU", so when the first privileged operation is done by the user, and then remember that authorization until app exit (or a timeout/screen lock event/...). But I have no idea if something like this is possible. |
|
Another round, with some simplifications and the polkit file: |
|
https://forum.sailfishos.org/t/migrating-configuration-and-data-files-for-sandboxed-apps/8866/46 Is seems a migration to a new config path is necessary after all. |
|
Right, so RC4 (plus one commit) seems to work fine. WRT Polkit, I have seen the following permissions used and asking for user confirmation:
My first approach would be to ship it with YES-YES-NO and see if users complain. @Olf0 what do you think? |
I am not sure yet, by reading the conversations at FSO and Jolla's SailJail documentation.
|
Cool & great! 😄
I prefer Yes-Yes-Yes, because that does not alter the extant behaviour: If a user clicks on "remove package", I think the intention is already properly expressed. It seems that you already came to the same conclusion, looking at your approfile branch (I hope I picked the right one with the most recent commits after the RC4 tag). P.S.: Note that I posed a minor beautification PR for this PKLA file. P.P.S.: AFAICS by a P.P.P.S.: And I have a few remarks and questions WRT your commits, see [1] and [2]. |
@attah, as the SailfishOS community meeting on IRC scheduled for the 21st July 2022 was cancelled, are you planning to pose the aforementioned question at the SailfishOS community meeting on IRC scheduled for the 4th August 2022? |
|
I was targeting the next one to be properly after vacations, and not to give minimum notice either. |
|
Thank you for pos(t)ing the question.
But unfortunately I fail to fully comprehend what these two sentences are meant to express (i.e., "parsing error"), especially the last part after the ellipsis ("…"). |
|
BTW @attah,
please take a look at the fourth sentence of the Sailjail README: "Target is to have application sandboxing enforced to all applications, starting from Sailfish OS 4.4.0." I filed an issue, asking what "all" is supposed to mean: "all apps by Jolla", "all apps at harbour" or "every app installed". Please also ask that at the IRC community meeting, if the answer prepared by Jolla (to our prior, original question) does not already provide this information. P.S.: Please try to avoid "jumping at conclusions", as you seem to have a tendency for that. |
|
Yes, i meant to ask it for 18 Aug, i.e. post this upcoming weekend.
Expanded/fixed: "if they already know where they are going, more-than-minimum time ahead of deadline is not needed." I just suspect that they could give a somewhat noncommittal answer if they feel done (which is what i believe), whereas concrete plans of additions gives a more concrete answer. So i wanted to give as much time as possible, thinking the answer might improve if more people see it beforehand.
Which shows the current set is good for some definition of all.
Isn't the question already "all apps at harbour" or "every app installed"? Please hold your bashing of my understanding to an "i told you so" after the meeting. We already agreed that the question is worth asking - i.e. i respect your position enough to take it seriously. My track record is just fine. Edit: And for the record i think (allowing) shipping a custom firejail profile is about as big of a hole as Sandboxing=Disabled (noblacklist is a thing for example) - and unless you somehow close both, neither makes sense to close. |
… again, if Jolla does not provide an answer without any of us being there, right?
Ah, thank you for the clarification. But by definition, the deadline they set for themselves ought to be sufficient, otherwise they might have set a longer deadline.
Jolla avoid non-committal answers like hell (correctly so), SailJail is not done at all (by looking at the gaps in the documentation, you mentioned that the Jolla Store app is not yet sailjailed etc.
Not really, they wrote that 9 months ago. Actually this probably just means really every application must ship a Sailjail profile with at least "Sailjail=Disabled", what we already know that it is coming.
Yes, agreed to all three questions. I forgot about the part of our question preceding the colon.
Sorry, I did not mean to bash. I simply wanted to clearly denote that I sense much interpretation ("I suspect, think, believe etc." and "Jolla could, might etc.", although I do see that you softened your occasional "will"), when there often simply is no information at all. To me the lack of information, which is the consequence of Jolla's information policy (which I do understand), just means "no information". And will try to avoid any "told you so", because I really have no idea what Jolla may answer. WRT your "Edit": Yes I also think that the security level achievable by Sailjail is debatable; this reminds me of the whole AppArmor (versus SE-Linux) story. But in both cases the Linux distributor is pushing it (Jolla rsp. SuSE), hence it will come. |
No, originally, since not everyone will be back yet. But since you asked that i do it now and i saw more likelihood of making this meeting, there was no point in insisting on sticking to my plan.
Not 100% of course (could have been forgotten), but it doesn't indicate failure either (like an edit to another version or to more vague terms would have).
No profile is already equal to using the default set of permissions. I don't see that it would need to change.
I agree with this, but draw very different conclusions.
As i said before, i think that if trusted-source apps can be trusted to be jailed with permissions presented to the user, that is as very reasonable and a good value. I see no evidence it will be pushed further. Let's see what shakes out... |
|
I suggest to close this issue. Sailjail=Disabled seems to be here to stay. |
|
I cannot follow your assessment (and the source needs to be documented here):
Andrew Branson's (abr) second statement was exactly one of the points I was concerned about Also note that "sailors" (i.e., Jolla employees) only call Jolla's own apps "system apps", while I would say Storeman and Patchmanager are system apps (in contrast to Jolla Mail or Jolla Browser); hence abr's statement that |
|
"Excellent" primarily responds to the first statement by abr. |
|
@nephros, as I am basically "done" with Storeman, finishing this (and the stalled "String rework" branch & PR #358) are two final steps left to execute (the "string rework" being my very own endeavour). The last message discussing this technically was the one on 2022-07-30 (i.e., exactly one year ago). As you did all the implementation work, I want to ask you first, if you would like to pick this up, again; it seems to be > 90% done. Note that I just posed a PR to your branch (please review, I hope it makes sense). Side note: The recent tag naming scheme allows for {alpha,beta,rc,release} versions being tagged in an SFOS-OBS compatible manner. I can easily create a |
|
Thanks for the ping and PR. I have to look through all of this so it may take a little time. |
|
IIRC my main concern with my branch is the polkit file. As the version of PolKit on SFOS does not support fine-grained permissions (as the xml/javascript based variant on newer polkit does), adding those permissions for 'group ssu' has the effect of all package install actions by the default user go through without confirmation, not only those triggered through Storeman. So that's a no-go. |
Thank you very much for your research, despite the slightly unfortunate but absolutely reasonable outcome. Side note: Those YAML with JavaScript based "configuration files" of polkit ≥ 0.106 are a security issue on their own; there are good reasons to keep code and config apart. The situation is so foobared that I documented it (with the focus on SFOS). Unfortunately I fail to find the LWN.net article which analysed and criticised this move (from Policykit 0.105 to 0.106) thoroughly. |
In theory one could create a separate user account for Storeman with its own access and Nothing I am keen on addressing while SFOS is on its demise and Storeman in maintenance mode. |
Oh, a second thought (as I have them quite often): IOW, are you absolutely sure, that the P.S.: The more and longer I work with and ponder about the concept of "controlled privilege escalation" as implemented by Policykit, |
|
Hello @nephros, I still would appreciate some feedback including your opinion on this (see my prior posting): Background: Before I close this issue in its current, unresolved state for good, I want to be sure to have no "think'o" in our considerations. I think I have discovered a logical mismatch in our considerations (see prior posting for details), but this might as well just be caused by me being afraid to miss something relevant or my lack of deeper knowledge how these mechanisms play together (or not). If you simply lack the time currently, that is fine, it is not at all urgent. In this case, please drop a terse line, e.g., "No time now.", "Outta time" etc. |
See PR #235 for the improper way.
For a proper one, study and utilise these:
Please also thoroughly document research results, evaluations / considerations and decisions met here, besides an implementation ((s), because there are multiple aspects and locations to alter), which is working and well tested. This can be done step by step, while documenting progress here.
Edit (2022-06-04):
harbour-storemanand leave the app name in the.desktopfile atharbour-storeman, because that maps to the extant path~/.local/share/harbour-storeman/harbour-storeman/config-files: No migration code, no copying of config files, all can stay the same! […] and this very similar alternative by rinigus@fso.The text was updated successfully, but these errors were encountered: