Comment 17 for bug 1393515

On 09/28/2015 04:48 PM, John Johansen wrote:
> On 09/28/2015 02:23 PM, Jamie Strandboge wrote:

>> a file browser in that it is read access. It is also true that lending
> a
>
> No, it is only by ui convention that the web browser is mostly read
> only. Users can still exploit it to load external content and save it
> to the file system, and an exploit can exploit the browser to have
> full access to the file system.
>
> ie. from a security pov mostly read access because of usage pattern
> still must be treated as full read/write because the write access is
> possible.
>
I meant to be clearer, I was talking about convention in this part.

>> points, but ultimately I agree with John-- we can do more, today, while
>> looking forward. How about having the (currently unconfined) webbrowser-
>> app intercept file:// and use content-hub? While I think there are some
>> UX issues to deal with (I doubt file:// access was considered in the
>> current implementation and merely a byproduct of the chromium content
>> api). This would then make it trivial to confine, would work in the
>> converged world and prevent trivial read access to data today.
>>
> so as long as this happens along with confinement, that would be acceptable.
> I don't care if the underlying access to the content hub is a hack, it
> is the browsers direct access to the filesystem that needs to be curtailed
>
Well, these are two different things (this bug and bug #1356516 (confinement))
that when combined achieve the result we want. My only point is that while there
are two bugs and they can thus be treated separately, there is nothing stopping
the webbrowser-app/oxide devs from integrating with content-hub. Plus, once that
is done, there is really no reason at all not to implement the confinement
policy immediately.

--
Jamie Strandboge http://www.ubuntu.com/