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 <allanp...@gmail.com> Sent: 01 April 2014 09:49 To: Dodier-Lazaro, Steve Cc: gnome-shell-list@gnome.org; desktop-devel-l...@gnome.org; gnome-keyring-l...@gnome.org Subject: Re: Request for comments on security of authentication/authorisation UIs Dodier-Lazaro, Steve <s.dodier-lazaro...@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 _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
