Collaboration on standard Wayland protocol extensions

[Martin Peres]

On 28/03/16 02:41, Jasper St. Pierre wrote:
> You're probably referring to my response when you say "GNOME does not
> care about cross-platform apps doing privileged operations". My
> response wasn't meant to be speaking on behalf of GNOME. These are my
> opinions and mine alone.

I must have mis-remembered then. Sorry.

> My opinion is still as follows: having seen how SELinux and PAM work
> out in practice, I'm skeptical of any "Security Module" which
> implements policy. The "module" part of it rarely happens, since
> people simply gravitate towards a standard policy. What's interesting
> to me isn't a piece of code that allows or rejects operations, it's
> the resulting UI *around* those operations and managing them, since
> that's really, at the end of the day, all the user cares about.

The UI is definitely the most important part of this work. I think
we gave already many ideas for the UI part in [1].

As much as possible, we want to avoid having the traditional
ACL-style because not only is it not easy to discover and tweak
but it is also going in the way of users. Instead, we would like
to be as unintrusive as possible.

We thus wanted to let distros take care of most of the policies (which
does not amount to much and will likely come with the application
anyway). However, some distros or devices come with a system
that already defines security policies and they will likely not want
a proliferation of storage places. Hence why we allowed for
multiple backends. But this is an exception rather than the rule.

What we envisioned was that when an app is using a privileged
interface, there would be a new icon in the notification area telling
which app is using what priviledged interface.

Also, when right clicking on a running window, there would be a
"capabilities" entry which, when clicked, would show on top of the
application what are the current capabilities allowed and what is
not. There, the user would be able to change the policy and have
multiple options for each capability:
- Default: (soft/hard allow/deny)
- One time granting (until the app is closed)
- One time revoke (revoke the rights immediatly)

> It would be a significant failure to me if we didn't have a standard
> way for a user to examine or recall the policy of an application,
> using whatever API they wanted. If every module implements its own
> policy store separately, such a UI would be extremely difficult to
> build.

Yes, you are most definitely right. We only provided a default policy,
but we also need a way to get feedback from the user about his/her
preferences.

One thing that is going to get problematic is what happens when
one updates a piece of software and the policy does not match
anymore. Since it is a pretty coarse grained policy, it should not
be an issue!

In any case, the user preference could be stored and managed by
libwsm and modules would only be called if no user preference is
found.

>  From what I read, Wayland Security Modules didn't seem to even provide
> that as a baseline, which is why I believe they're tackling the
> problem from the wrong angle.

We attacked the problem from a UX point of view and then a distro
point of view. The custom configuration was a bit left on the side
since experimented users could write their own file and more novice
users would likely be more than OK with a runtime GUI to manage
the rights and allow granting privileges when needed.

We most definitely do not wish to ever have something as annoying
as the UAC in Linux, constantly asking the user for permissions on
things the user has no understanding about.

I really think that the 4 levels proposed by libwsm make a lot of sense
to reduce annoyance as much as possible [2]

[1] http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
[2] https://github.com/mupuf/libwsm