[Elementary-dev-community] elementary's path forward for application containment and security.

[Cameron Norman]

Hello all,

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 webcam 
option.


These are the changes/additions that I think could make this possible:
* 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 programming :).


Lennart Poettering's presentation of portals at GUADEC 2013, starting 
at 35:00.


Ubuntu Mobile's "Content Hub".

Thank you very much for reading,
--
Cameron Norman 
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] elementary's path forward for application containment and security.

[Daniel Foré]

Hey Cameron,


I've been thinking about app containment too and I know I feel better on iOS 
that apps have to ask my permission to use things like location services.




I think it would be worth looking at the solutions from both Canonical and 
GNOME first before we go building our own solution. 
Cheers,

Daniel Foré
elementaryos.org

On Tue, Mar 18, 2014 at 6:36 PM, Cameron Norman 
wrote:

> Hello all,
> 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 webcam 
> option.
> These are the changes/additions that I think could make this possible:
>  * 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 programming :).
> Lennart Poettering's presentation of portals at GUADEC 2013, starting 
> at 35:00.
> Ubuntu Mobile's "Content Hub".
> Thank you very much for reading,
> --
> Cameron Norman -- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] elementary's path forward for application containment and security.

[Cameron Norman]

Yes, I can definitely see how much this would expand Contractor's 
scope, but it is possible that we could engage with the GNOME community 
to work on Contractor, since it does not seem like Lennart Poettering 
has begun the portals work.


Content Hub seems to be already developed, but its API is QML, so a 
GObject wrapper is probably necessary (maybe in Granite?).


--
Cameron Norman

El Tue, 18 de Mar 2014 a las 6:39 PM, Daniel Foré 
 escribió:

Hey Cameron,

I've been thinking about app containment too and I know I feel better 
on iOS that apps have to ask my permission to use things like 
location services.


I think it would be worth looking at the solutions from both 
Canonical and GNOME first before we go building our own solution. 
Cheers,


Daniel Foré
elementaryos.org


On Tue, Mar 18, 2014 at 6:36 PM, Cameron Norman 
 wrote:



Hello all,

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 
webcam option.


These are the changes/additions that I think could make this 
possible:

 * 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 
programming :).


Lennart Poettering's presentation of portals at GUADEC 2013, 
starting at 35:00.


Ubuntu Mobile's "Content Hub".

Thank you very much for reading,
--
Cameron Norman 




-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] elementary's path forward for application containment and security.

[Akshay Shekher]

Hey Cameron,
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"  wrote:

> Hello all,
>
> 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 webcam option.
>
> These are the changes/additions that I think could make this possible:
>  * 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 programming :).
>
> Lennart Poettering's presentation of portals at GUADEC 2013, starting at
> 35:00.
>
> Ubuntu Mobile's "Content 
> Hub".
>
> Thank you very much for reading,
> --
> Cameron Norman
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] elementary's path forward for application containment and security.

[Cameron Norman]

Hello Akshay,

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 
 escribió:

Hey Cameron,
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"  
wrote:

Hello all,

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 
webcam option.


These are the changes/additions that I think could make this 
possible:

 * 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 
programming :).


Lennart Poettering's presentation of portals at GUADEC 2013, 
starting at 35:00.


Ubuntu Mobile's "Content Hub".

Thank you very much for reading,
--
Cameron Norman 


--
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp


-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] elementary's path forward for application containment and security.

[Akshay Shekher]

The earlier implementation IIRC worked in the following way.

App -> contractor [give me a list if programs that handle file type x]

<- [program a b ... ..]

App asks the user to select one or selects one itself and

App -> Contractor [program Id x, for file/uri y]

<-  [command string]

App executes this using execv or something similar.

The '->' is for dbus function calls and '<-' for return.
Dbus is just a protocol for doing interprocess communication so a
program/script can use contractor if it can use dbus.
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] elementary's path forward for application containment and security.

[Cameron Norman]

I guess what I do not understand is how the application gets the data 
by executing the command. What I see in that implementation is simply a 
return of a command to run with an existing file as an argument, 
instead of a way to retrieve a new file.


The difference is that the former says "I have a , what can I do 
with it?" while the latter says "I want to do something with a , 
how/where can I get one?".


El Tue, 18 de Mar 2014 a las 8:45 PM, Akshay Shekher 
 escribió:

The earlier implementation IIRC worked in the following way.

App -> contractor [give me a list if programs that handle file type x]

<- [program a b ... ..]

App asks the user to select one or selects one itself and

App -> Contractor [program Id x, for file/uri y]

<-  [command string]

App executes this using execv or something similar.

The '->' is for dbus function calls and '<-' for return.
Dbus is just a protocol for doing interprocess communication so a 
program/script can use contractor if it can use dbus.
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] elementary's path forward for application containment and security.

[Akshay Shekher]

Contractor only implements the first one it does not fetch data for an app,
it just enables the application to send its data to another application for
further work.

The latter would require more work on the 3rd party application while the
current setup just needs a contract file and everything else works.
On Mar 19, 2014 9:59 AM, "Cameron Norman"  wrote:

> I guess what I do not understand is how the application gets the data by
> executing the command. What I see in that implementation is simply a return
> of a command to run with an existing file as an argument, instead of a way
> to retrieve a new file.
>
> The difference is that the former says "I have a , what can I do
> with it?" while the latter says "I want to do something with a ,
> how/where can I get one?".
>
> El Tue, 18 de Mar 2014 a las 8:45 PM, Akshay Shekher <
> voldyman...@gmail.com> escribió:
>
> The earlier implementation IIRC worked in the following way.
>
> App -> contractor [give me a list if programs that handle file type x]
>
> <- [program a b ... ..]
>
> App asks the user to select one or selects one itself and
>
> App -> Contractor [program Id x, for file/uri y]
>
> <-  [command string]
>
> App executes this using execv or something similar.
>
> The '->' is for dbus function calls and '<-' for return.
> Dbus is just a protocol for doing interprocess communication so a
> program/script can use contractor if it can use dbus.
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp