[sailfishos/udisks2] Policies set very lax

Platform Development
#1

This issue was filed in August 2020, plus some details added in the following months: Policies set very lax (#2) · Issues · mer-core / udisks2 · GitLab

In June 2021, I took the chance (when Jolla started to address the open Merge Requests at https://git.sailfishos.org/ in order to close their Gitlab instance) to bring this to @tomin’s attention (who handled the MRs left open there) and received as reply:

I mentioned about this internally but I didn’t get any response yet. […]

Because mer-core · GitLab has been put into archived state a few days after this little, initial conversation about this issue, and the issue tracker at GitHub - sailfishos/udisks2 is switched off, this issue has to be re-filed here to be able to track and discuss it any longer.

I still would appreciate any feedback on the content of this issue (in contrast to formal feedback, as already provided).

P.S.: Cut & Paste of the core content of this issue (for details, see the original issue report).

Policies set very lax

Per 0003-Loosen-up-polkit-policies-to-work-from-another-seat.patch the policy rules for polkit are broadly set from their quite strict defaults to “very open”, specifically from <allow_any>auth_admin</allow_any> to <allow_any>yes</allow_any> for all mounting and unmounting rules!
This may easily introduce security issues. This is exacerbated by commit d20b9c18, which now automatically mounts SD-cards etc. from any user context.

A viable, safer way might be to allow slightly more generous policies for specific Unix user groups (as e.g. my 69-cryptosd.pkla did), primarily for the mounting and unmounting rules. The loosening of the other rules appears to be reasonable (to me), specifically those altered from <allow_any>auth_*</allow_any> (with * e.g. admin ) to a more lax <allow_any>auth_*</allow_any> (with * e.g. self ).

IOW, for those policy rules, which 0003-Loosen-up-polkit-policies-to-work-from-another-seat.patch alters from from auth_* / auth_* / auth_* to any / any / any (i.e., for the mount and unmount rules there), please consider to additionally restrict them to specific UNIX groups per Identity=unix-group:xyz or some other form of Identity= -statement.

At most one may handle this as I do in [mount-sdcard]: 61-mountsd.pkla, which has been successfully tested for quite a while with mount-sdcard by a some ten users: It extends many access rights, but only for specific users / groups.

2 Likes
Migrating Sailfish OS git repos to Github
#2

Forgive my ignorance; but what is the problem with the policy being lax?
I have found that it usually gets better responses if that is made clear.
Of course, if it can be stricter without ill effect, it probably should… but still.

#3

Security!
The polkit maintainers have good reasons for making these access rules quite strict. They have to be loosened to allow for what Jolla wants to achieve here, but “anything goes” is inappropriate, as pointed out above and in the original issue report.

P.S.: This is one of the long-standing issues SailfishOS has, which IMO renders the efforts and discussions about features specifically aimed at security (e.g., encryption and fire jail) a bit laughable academic.

P.P.S.: Actually I already stated that concisely, above.

This may easily introduce security issues. This is exacerbated by commit d20b9c18, which now automatically mounts SD-cards etc. from any user context.

#4

Do I understand correctly, that you could remount the storages to get access to parts of the filesystem which would otherwise be blocked by firejail? Does that actually work?

Or did you have another vector of attack in mind?

1 Like
#5

Please take a look at Jolla’s changes, which are linked in the original post:
They allow any user to mount, re-mount, bind-mount or unmount anything without authentication.
They also allow to modify any device (access rights etc.) by any user with his own authentication.

By (Polkit’s) default, most of these actions are only allowed with admin authentication.

Being able to execute arbitrary mounts, re-mounts and bind-mounts have provided nice attack paths in the past, this is why the Polkit maintainers have tightened these policies multiple times.
As I am not a Firejail expert, I cannot tell for sure, if that is useful for circumventing it: You may ponder about that and try.