Re: gnome-keyring Request for comments on security of authentication/authorisation UIs

["Dodier-Lazaro, Steve" <s dodier-lazaro 12 ucl ac uk>]

Hello,

> > One does one keep informed about this? Where do I sign up?
>
> That's a good question. You can subscribe to the wiki page that I
> linked to, follow this mailing list, and follow Planet GNOME. I'm sure
> that there will be traffic on this topic once we make progress.

Done, thanks. It seems to me there is no specific place to discuss the relationships between sandboxing and 
"data sharing models" at the moment. I don't want to just keep in touch, in a sense, but I'm very willing to 
contribute time and effort (including coding stuff) to make sandboxed apps happen. I happen to be paid to do 
exactly that (though at the "research prototype" level of quality, not production-ready code).

Questions that come to mind are: should there be a specific place to discuss sandboxing and its implications 
(seems to me all the interested parties are already GNOME devs, except maybe for Dan Walsh and Ikey Doherty)? 
Is this ML ok to use? Do you welcome contributors external to GNOME? The question is maybe a bit stupid, but 
I've had bad experiences with Ayatana and I wouldn't want people to think that I'm a guy coming out of 
nowhere stepping on their toes and contributing nothing useful.


> I don't think we've fully decided what kind of mode we'll use for
> "sharing". You're right that it could be purely about publishing, or
> sharing between people. Another model is that sharing becomes the
> generic action for passing data between apps, or between apps and
> devices: eg. a document viewer could say "share this document with my
> printer".

I've been browsing through the desktop-devel archives and found a post by Ikey about sandboxing apps, it 
seems you guys discussed already quite a bunch of things related to how Portals operate. I now understand 
better what you meant by using a Share mechanism.

Basically I think the following principles must hold true to ensure a mechanism to share/access data cannot 
be abused by a sandboxed app:
- there must be an end-to-end trusted path between the user's input and the system (hear, OS or compositor) 
and between the system and output to the user
- or there must be some form of indirection outside of the app's control to modify / request system/user data

Contrarily to Ikey's proposal, I think a lot of this can be achieved transparently for app developers (though 
probably not all of it). For instance for file dialogs I'm quite confident that all apps that only using the 
standard features of the GtkFileChooserDialog class could be ported to having a Portal-provided dialog. I'm 
trying right now to write a subclass that turns every method into a DBus call for a server to recompose the 
dialog on its end (which is not w/out security implications e.g. DoS attacks but let's leave this aside for 
now). With such a dialog, the provider could just do a mount bind to the selected file in the sandbox and 
then return the filename for the app to transparently open the file. Of course many apps would still fail 
because they do non-standard stuff, but at least apps that behave properly would avoid rewriting with a new 
API. All it takes is linking to a new GTK+ lib.

The print dialog could work likewise since you'd normally get a Print dialog 
(https://developer.gnome.org/gtk3/stable/GtkPrintUnixDialog.html for Linux at least). So, adding an 
indirection such as "Share with printer" that then pops the dialog may be unnecessary for this case?

Now, it seems very easy when looking at apps outputing some information for some other component of the 
system. All you need is them to use an API that opens a DE-controlled GUI. Likewise the very basic file 
opening use case maps very well. I'm just starting to think about more complex file usage models, and about 
how to support them. For instance some apps naturally open and process large amounts of files. A music player 
typically wants to scan entire folders for relevant files. If you take Exaile's collection manager 
(http://sidi.mupuf.org/files/exaile-collection.png), this could probably be made into a third-party 
dialog/widget* that exposes folders, and restricted to a specific mime type or read-only access with just a 
few clicks. If that was proposed as a GTK widget then apps could be tempted to outsource this aspect to the 
GTK widget and these apps could then be sandboxed without disruption?

Other typical use/cases are when a user processes some data from one app to another (e.g. download an image, 
crop/modify it, include it into a document). In this case a generic "Share with ... app" mechanism may be 
more powerful and nicer than the current save file to FS, open next app, open file in app, save modified 
file, etc. workflow. The hardest use case for me so far is when you manipulate some file in two apps at a 
time (maybe typing some document in an editor and then looking at the outcome in a viewer). The apps would 
need to share their sandbox, or to read and write simultaneously on the FS or use IPC.

Even more annoying use cases: assume I have a browser/music player (typical apps that use DBus to redirect 
you to a running instance when you relaunch them) running in a sandbox and launch a new instance of it. 
Should I be redirect to the existing app or should a new / separated process open up? Typically for a browser 
you might want to manage different profiles so you can visit your bank website without worries, while for the 
music player you rarely want two instances.

I don't think it should be up to users to decide what to sandbox or how apps should behave. First because 
they have no clue what security risks exist out there (which I wouldn't blame them for :) ) and second 
because they like to stick to defaults, so an optional sandbox would just accumulate dust in the corners of 
their OS, for most of them. That's why I'm interested in first finding out whether we can design general 
interactions / APIs that fit the vast majority of apps out there and for which we can write sensible default 
policies. If that fails then we can fallback to optional sandboxing that's more constraining on the user and 
app developer.

Would you like me to put these down on a wiki page so we can extend and find for which use cases problems 
arise? This would also reduce the risk of the existing discussions being lost, should other people jump in 
the train and contribute ideas.

Thanks,
--
Steve Dodier-Lazaro
PhD student in Information Security
University College London
Dept. of Computer Science
Malet Place Engineering, 6.07
Gower Street, London WC1E 6BT
OpenPGP : 1B6B1670
________________________________________
From: Allan Day <allanpday gmail com>
Sent: 01 April 2014 09:49
To: Dodier-Lazaro, Steve
Cc: gnome-shell-list gnome org; desktop-devel-list gnome org; gnome-keyring-list gnome org
Subject: Re: Request for comments on security of authentication/authorisation UIs

Dodier-Lazaro, Steve <s dodier-lazaro 12 ucl ac uk> wrote:
...
> > I'm afraid we don't currently have a clear plan for how all the pieces
> > will fit together, but we do have ideas and are looking to develop a
> > concrete plan for the UX in the near future.
>
> One does one keep informed about this? Where do I sign up?

That's a good question. You can subscribe to the wiki page that I
linked to, follow this mailing list, and follow Planet GNOME. I'm sure
that there will be traffic on this topic once we make progress.

> > One relevant area is
> > sharing [1], as the UX mechanism through which it is possible to share
> > data between applications.
>
> Interesting. It seems these UIs play a specific goal though, maybe better coined
> as "Publishing" to specific destinations made compatible one by one. There are
> many different models for how an app may process the user's data and how you could
> combine apps. I've been trying to think of sandboxing in terms that don't involve
> me having to figure out / describe / support these models at all but there is a
> lot of research to do to find the right approach to data sharing for sandboxed apps.
> There isn't a single existing product I'm happy with, but this is maybe off-topic
> for now (very happy to discuss it elsewhere though).
...

I don't think we've fully decided what kind of mode we'll use for
"sharing". You're right that it could be purely about publishing, or
sharing between people. Another model is that sharing becomes the
generic action for passing data between apps, or between apps and
devices: eg. a document viewer could say "share this document with my
printer".

Allan