** Changed in: canonical-devices-system-image
Status: Fix Committed => Fix Released
--
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
Since version 0.23+15.10.20151005-0ubuntu1, webbrowser-app runs under
apparmor confinement, so browsing the filesystem is denied.
** No longer affects: webbrowser-app (Ubuntu RTM)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
** Changed in: canonical-devices-system-image
Milestone: ww46-2015 => ww40-2015
** Changed in: canonical-devices-system-image
Status: Confirmed => Fix Committed
** Changed in: webbrowser-app (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification
assigning to jamie for a decision on short term approach
** Changed in: canonical-devices-system-image
Importance: Undecided => Critical
** Changed in: canonical-devices-system-image
Status: New => Confirmed
** Changed in: canonical-devices-system-image
Milestone: None =>
@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
@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
@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
FYI, the oxide/webbrowser-app devs believe '4' is the path forward and
have started on it.
** Changed in: canonical-devices-system-image
Assignee: Jamie Strandboge (jdstrand) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
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
@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
Are file: URI's used by content hub to identify resources?
--
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
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
Removing myself from assignment since I answered Pat's question.
--
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
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
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://
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.
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
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
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
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 ...
--
You
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
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
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
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
FYI, per
https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData
this needs to be fixed (in some manner). This should happen for OTA-1.
** Information type changed from Private Security to Public Security
** Tags added: ota-1
** Changed in: webbrowser-app (Ubuntu)
Importance:
Without this fix, the other protections made in the file manager and
elsewhere are meaningless.
** Description changed:
- using a URL like: file:/// gets you to the root of the phone filesystem
+ Using a URL like: file:/// gets you to the root of the phone filesystem
... i assume this is not
Note, running confined will break the current workaround behavior for
keepDisplayOn.
--
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
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?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
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.
--
You received this bug notification because you are a
29 matches
Mail list logo
