touch-packages team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

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/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu.
https://bugs.launchpad.net/bugs/1393515

Title:
  browser allows browsing the phone filesystem

Status in webbrowser-app package in Ubuntu:
  Confirmed
Status in webbrowser-app package in Ubuntu RTM:
  Confirmed

Bug description:
  Using a URL like: file:/// gets you to the root of the phone
  filesystem ... i assume this is not actually desired since we even
  block the filemanager app to go higher up then $HOME without requiring
  a password.

  The webbrowser-app should either:
   * behave like the file-manager (see bug #1347010 for details)
   * file:/// should be disabled altogether on the phone
   * webbrowser-app should run confined which would force the use of
     content-hub by limiting file:/// access to those paths allowed by
     policy

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1393515/+subscriptions