browser allows browsing the phone filesystem

Neither preferences.allowFileAccessFromFileUrls nor preferences.allowUniversalAccessFromFileUrls allow controlling this behaviour.

There is no mechanism in oxide to restrict filesystem browsing.
Instead, what we should do is ensure that the browser runs confined (see bug #1356516).

FYI, per https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData this needs to be fixed (in some manner). This should happen for OTA-1.

Without this fix, the other protections made in the file manager and elsewhere are meaningless.

Note, running confined will break the current workaround behavior for keepDisplayOn.

> Note, running confined will break the current workaround
> behavior for keepDisplayOn.

Unless we tweak the apparmor profile to allow D-Bus calls to com.canonical.Unity.Screen, right?

Actually, I was thinking webbrowser-app policy would be a click profile, but it would be only based on a click profile-- we could add whatever we want to it so keepDisplayOn and any other DBus accesses can just be added to the profile.

this seems to take a little longer :)
yet it got us bad press already ... https://www.glasswall.nl/ubuntu-phone-security-we-zijn-er-nog-niet/

how about we intercept the file:// protocol on the UI level so it doesnt get handed to the oxide backend until the actual fix is in place ...

I think the web browser is different from the file browser. If you hand your phone to a stranger, unlocked, with the intention that they can use the phone to dial someone or view the wikipedia entry for a topic under debate or check the weather or whatever, you'd really like it to be difficult for the person to make your life miserable. Dangerous operations should require re-prompting with pin or password.

The file browser would allow someone to add .ssh/authorized_keys or other similar tricks. The web-browser is, as far as I know, a mostly-read interface that would have great deal of difficulty modifying content. Granted that there may be plaintext data on the phone that a user wouldn't want a stranger to have easy read access to, but that data should probably be stored encrypted anyway.

well, we store at least a plaintext password in the syncevolution settings which the article i linked to complains about ...

and you cant really make sure that an app doesnt do the same in its applicatiopn config dir, we simply dont control that.
so having the browser ignore or deny the file:// protocol would be a quick way to prevent that (and i must say i personally dont really see a need to support file:/// on a phone)

On 09/28/2015 11:56 AM, Seth Arnold wrote:
> I think the web browser is different from the file browser. If you hand
> your phone to a stranger, unlocked, with the intention that they can use
> the phone to dial someone or view the wikipedia entry for a topic under
> debate or check the weather or whatever, you'd really like it to be
> difficult for the person to make your life miserable. Dangerous
> operations should require re-prompting with pin or password.
>
> The file browser would allow someone to add .ssh/authorized_keys or
> other similar tricks. The web-browser is, as far as I know, a mostly-
> read interface that would have great deal of difficulty modifying
> content. Granted that there may be plaintext data on the phone that a
> user wouldn't want a stranger to have easy read access to, but that data
> should probably be stored encrypted anyway.
>
Sorry I need a little more context. Is the browser using the content hub
to browse these files? If not it is a security problem, browsers can not
be trusted, there are too many attack surfaces/vulnerabilities and
allowing it direct access to the fs, except where explicitly allowed
by policy, violates our security model. In this case blocking file://
is not sufficient, that relies on the browser behaving correctly,
which means assuming there are no vulnerabilities in the browser.

If however the browsing is done via the content hub and the user is granting
permission to the browser to access files, then this is out of scope. That
is if the owner hands their phone over to a 3rd party it is the owners
responsibility to make sure their data is secured in ways that a regular
user can not access it (ie, encrypted or stored in a separate user
account).

On 09/28/2015 12:56 PM, Oliver Grawert wrote:
> well, we store at least a plaintext password in the syncevolution
> settings which the article i linked to complains about ...
>
> and you cant really make sure that an app doesnt do the same in its applicatiopn config dir, we simply dont control that.
> so having the browser ignore or deny the file:// protocol would be a quick way to prevent that (and i must say i personally dont really see a need to support file:/// on a phone)
>
Again intercepting the file:// protocol on the ui is a band aid and does not fix the problem, if the file system is still available to any exploit. The only solution is correct confinement and using content hub style access and delegation of access.

Oliver, except it's not a phone, it's a converged computing device; I use file:/// browsing in my desktop and expect to be able to do the same when I replace my desktop with my phone, monitor, keyboard, and mouse.

John, I agree that the long run should definitely include an AppArmor profile on the browser and use content hub when trying to browse outside of that. I just wanted to make the case that blocking file:/// access isn't the best way forward, and trying to implement a piece-meal security policy via UI modifications is building technical debt that's better left unsolved rather than handled poorly. Thanks for forcing a clarification.

Thanks

On 09/28/2015 01:41 PM, Seth Arnold wrote:
> Oliver, except it's not a phone, it's a converged computing device; I
> use file:/// browsing in my desktop and expect to be able to do the same
> when I replace my desktop with my phone, monitor, keyboard, and mouse.
>
> John, I agree that the long run should definitely include an AppArmor
> profile on the browser and use content hub when trying to browse outside
> of that. I just wanted to make the case that blocking file:/// access
> isn't the best way forward, and trying to implement a piece-meal
> security policy via UI modifications is building technical debt that's
> better left unsolved rather than handled poorly. Thanks for forcing a
> clarification.
>
Oh I agree this has to be treated as a hybrid device, not just a phone.
The point I am trying to make is that even just temporarily blocking
file:// via the ui does not address the problem.

The browser still has file access and any vulnerability can take
advantage of it.

Currently the webbrowser is not confined (there is another bug for that) but webapps are (so this bug doesn't affect, say, facebook in the store, but it does affect webbrowser-app). There is a bug to confine webbrowser-app and I agree that with that confinement should come content-hub integration.

This use case Seth pointed out falls under https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData and we are still in 'Phase 1': "For Phase 1, users desiring privacy and elevated security against casual theft should enable a PIN/password, protect that PIN/password against theft and not lend the phone to people they do not trust". In other words, the current implementation does not protect against lending to a bad actor-- there is only so much we can do without a guest account on the system designed for lending.

But, we haven't done all we can do without a guest account (ie, phase 1) yet and we shouldn't make it trivial to access potentially sensitive data. Seth is right to point out that the web browser is different than a file browser in that it is read access. It is also true that lending a phone to someone with your open session allows them to open all your apps as you (eg, adjust your email settings, request a password reset from facebook, etc). I think the website misses some of these finer 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.

On 09/28/2015 02:23 PM, Jamie Strandboge wrote:
> Currently the webbrowser is not confined (there is another bug for that)
> but webapps are (so this bug doesn't affect, say, facebook in the store,
> but it does affect webbrowser-app). There is a bug to confine
> webbrowser-app and I agree that with that confinement should come
> content-hub integration.
>
> This use case Seth pointed out falls under
> https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData
> and we are still in 'Phase 1': "For Phase 1, users desiring privacy and
> elevated security against casual theft should enable a PIN/password,
> protect that PIN/password against theft and not lend the phone to people
> they do not trust". In other words, the current implementation does not
> protect against lending to a bad actor-- there is only so much we can do
> without a guest account on the system designed for lending.
>
Yes bad actor is out of scope

> But, we haven't done all we can do without a guest account (ie, phase 1)
> yet and we shouldn't make it trivial to access potentially sensitive
> data. Seth is right to point out that the web browser is different than
right alternate user/guest user accounts are part of the solution to
the bad actor problem but outside of the scope of the web browser being
a problem.

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

> phone to someone with your open session allows them to open all your
> apps as you (eg, adjust your email settings, request a password reset
> from facebook, etc). I think the website misses some of these finer
of course again, don't give your phone to a bad actor

> 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

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/

@john ... i do not want to keep teh browser unconfined but currently we have a widely gaping security hole that allows everyone to read any cleartext password any third party app stores in the users home. i have no doubt that adding confinement is the right solution, can you implement it for the next OTA (yes this was rhetoric) ... ?

today if a user uses some third party facebook web app that stores his PW in a cleartext cookie that user cant hand his device unlocked to someone else without immediately risking that they can read his PW ... i know intercepting the file protocol isnt a solution, but applying such a band aid until the actual solution is in place to protect our users seems accceptable to me vs having this issue open for another year with actual customers out there being vulnerable ...

@seth we are at least 6 months away from an actual "hybrid device" (none of the phones sold today will be capable to run like this due to driver or HW limitations). i have some hope that we have an actual confinement fix in place once the converged device is actually out there ... but do we really want to keep current customers that bought an ubuntu phone because they belive in the added security of our concept vulnerable like this ?

all i'm asking for is a fix that doesnt take another year, this bug is 10 months old and nobody has even started the work on the actual fix. yes, intercepting file:// isnt shiny or nice but we have people out there running around with this bug, will we just leave them in the cold for another 6 months ?

assigning to jamie for a decision on short term approach

There are several options:
1. capture file:// and ignore it in the short-term, add confinement and content-hub later
2. add confinement and content-hub now
3. add content-hub now and confinement later
4. add confinement now and content-hub later
5. do nothing

'5' is probably out of the question at this point, since it is the status quo and it is clear no one is happy with it. :)

'1' is an option as a band-aid, but it requires development work. It isn't clear to me that capturing file contributes to using content-hub later. This is possibly a short term fix.

'2' fixes everything all at once. This would require talking work away from other areas and needs design input. This is a medium term fix.

'3' is similar to '1', but makes sure we are in alignment for future engineering work. This is a medium term fix.

'4' has a similar affect to '1' in that it breaks file:// access, but also covers any other access. It can be a short term fix and aligns with future engineering work.

I believe '4' (this is bug #1356516) is the path forward in the short term. It addresses the security and privacy concerns and aligns with future engineering work. For convergence, content-hub integration will be a requirement. I'll discuss this with the oxide team and report back.

Can I kill option 1 right away? Capturing file:// in the browser won't even work as a band-aid in the short term. All it would take to get around that would be for me to open a page that contains some links to file: URLs and navigate to them. Yes, we have an API to intercept navigations in the main frame, but then I could get around that by making sure they navigate a subframe. Even if we had an API to intercept subframe navigations (and we definitely shouldn't), a webpage can still embed media or image elements pointing to file: URLs (of course, same origin restrictions prevent a remote attacker from being able to access the contents them, but a page can still display them to the user).

Are file: URI's used by content hub to identify resources?

FYI, the oxide/webbrowser-app devs believe '4' is the path forward and have started on it.

Removing myself from assignment since I answered Pat's question.

We just discussed this, and I think I've misunderstood how content hub works. IIUC, you can't address resources directly but it asks the user to pick a resource.

I was thinking that we could implement a replacement protocol handler for file: URIs that could delegate to content hub when we can't access a resource due to confinement, but it's clear that this would not really fit with how content hub works

@chrisccoulson: that's correct, you can't address resources directly. But we could use the files-app to provide a picker for choosing files to load, which would create a link to the files in a location accessible by the browser under confinement. Although I don't think that would really work, you would need to provide more than single files right? The resource may require addition resources that are relative right?

@chrisccoulson and @ken-vandine: I think that what we can do is leave file:// alone and let apparmor policy make sure it can only access what is needed behind the scenes (already works for webapps). Then for File/Open style-functionality (eg, in convergence) we do the content-hub file-picker as you suggested.

This means that file:// specified in the location bar is pretty limited-- I wonder if it is worth disabling (but probably not, it will have some utility in the app-specific areas) or oxide/webbrowser-app could check the return code and return something more helpful than a blank page. IMHO, returning a blank page for file:// accesses outside of the app-specific areas is of course fine security-wise and is a matter of UX.

Since version 0.23+15.10.20151005-0ubuntu1, webbrowser-app runs under apparmor confinement, so browsing the filesystem is denied.