On Tue, 2014-04-01 at 18:55 +0000, Dodier-Lazaro, Steve wrote: > 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. > Probably time I presented myself as.. present.. again :) > 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
Well, you're probably right there. I was thinking more of catch-all cases.. but we should be maintaining a consistent usage of API. Having it happen transparently through existing systems makes most sense, i.e. via GtkFileChooser, GApplication, etc. (Modified launch context wouldn't hurt either) Point me in the rough general direction when you've got a bit of an idea on how it wants to be implemented, and I'll turn it into codes (TM) (An idea doing the rounds is implementing the helper within systemd, ensuring a sane init daemon is present in this sandbox, enabling proper kdbus, security, launching of the the process itself, and ensuring the use of pivot_root and bind-mounts) - Ikey > ________________________________________ > From: Allan Day <[email protected]> > Sent: 01 April 2014 09:49 > To: Dodier-Lazaro, Steve > Cc: [email protected]; [email protected]; > [email protected] > Subject: Re: Request for comments on security of authentication/authorisation > UIs > > Dodier-Lazaro, Steve <[email protected]> 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 > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
