elementary-dev-community team mailing list archive
Mailing list archive
Re: elementary's path forward for application containment and security.
Could you clarify the process of how the data was returned?
Ubuntu's Content Hub has a nice methodology to accomplish this. It has
an, what I assume to be QML, object that represents the transfer, and
the data is transferred through that, not by running a command.
Perhaps Contractor could return the data as dbus objects? This would
allow for the third item I mentioned, which is type marshaling.
El Tue, 18 de Mar 2014 a las 7:09 PM, Akshay Shekher
What you are describing sounds very similar to androids intent system.
The fist version of contractor did return data but the problem with
that was the application had to execute a command returned as a
string so if a program was running as root and a malicious program
used the same dbus config as contractor then it could do lots of harm.
Shnatel and I had discussed the contractors implementation and
decided against returning data directly.
I am open to discussion on the topic though.
On Mar 19, 2014 7:06 AM, "Cameron Norman" <camerontnorman@xxxxxxxxx>
I recently have taken an interest in some of the containment and
security features being developed for Ubuntu touch, as well as
Lennart Poettering's plans for containment on GNOME.
One of the recurring aspects that I see is a "Content Hub" (Ubuntu)
or "application Portals" (GNOME) system. Both of these have
remarkable similarity (in concept) to elementary's Contractor.
Although many of you most likely did not foresee Contractor's role
in security when it was created, it undoubtedly does have one. By
delegating out responsibilities (such as, say, printing), Contractor
allows for the removal of privileges from an application. If all
applications are using the print contract, there is no need for
those applications to have the capability to use the printer.
By extending Contractor's scope (or moving to another service)
further containment, as well as better features, is possible.
Specifically, returning data, instead of handing them off, will
allow for increased consolidation of privileges.
The open and save GTK file dialogs are great example. If apps use
contracts to perform these functions, they do not need to be given
the privilege of directly reading or writing to the user's
documents, pictures, emails, etc.
Another good example is retrieving a profile photo. Instead of
having every social media app be able to directly access the webcam,
they could ask Contractor for a photo, and contractor could give the
These are the changes/additions that I think could make this
* returning data instead of just handing it off
* ability to call a contract by name (e.g. "Print" or "OpenFile")
* passing / returning more types of data: not just files, but also
strings, booleans, or URLs
Before I go into detail about how I have been thinking about
exposing this functionality, I would like to hear all of your
thoughts about the merit of these changes, and if any of you would
like to develop these things with me (heads up: I suck at
Lennart Poettering's presentation of portals at GUADEC 2013,
starting at 35:00.
Ubuntu Mobile's "Content Hub".
Thank you very much for reading,
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help : https://help.launchpad.net/ListHelp