Deprecate and remove overly-powerful permissions #1152
Comments
|
The problem of course is access to X11; that'd impact everything. Though I could see it being useful to have the child X server be a builtin feature...there's lots of precedent for this. I'd love to have a global switch which forces off access to |
|
It just has to be a slow transition and perhaps less marketing calling it "secure" in the short term. Too many applications have to have holes to be usable, and "secure" also depends upon your definition. For example direct video card access is potentially very scary but we are a ways off from having a secure alternative to that (which will be much slower). |
|
We want to ask for permissions before install and on update, tracked here: #275 However, completely dissallowing this is not a goal. We want to allow packaging existing apps, and most existing apps will not work without these permissions. In the future as we make the portals framework work and convert apps to use it things will get better, but right now if we didn't have this flatpak would be useless for anything but games. We do support overriding app permissions, and we should perhaps have a global override feature that affects all apps. |
|
@TingPing What would the secure alternative be? @cgwalters I very much believe that we need to use a child X server and/or require Wayland as a mandatory dependency. |
|
What does Chromium do?
…On Nov 12, 2017 6:30 PM, "TingPing" ***@***.***> wrote:
@TingPing <https://github.com/tingping> What would the secure alternative
be?
Few options like just relying on software rendering or something like
virgl <https://virgil3d.github.io/>.
I vaguely remember another low level GPU virtualization research project
but I can't find it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1152 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGGWB2iDoGXsjmhH6LDzlIufjdAIvEZPks5s13-lgaJpZM4QUUq3>
.
|
|
@DemiMarie It doesn't expose normal OpenGL to websites it only exposes WebGL which has less features and a few behaviors designed for better security such as zeroing out any memory before its handed to you (which is of course slower but probably reasonable). |
|
I mean, “What does Chromium’s sandbox do regarding OpenGL?”
…On Nov 13, 2017 12:49 PM, "TingPing" ***@***.***> wrote:
@DemiMarie <https://github.com/demimarie> It doesn't expose normal OpenGL
to websites it only exposes WebGL which has a few behaviors designed for
better security such as zeroing out any memory before its handed to you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1152 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGGWB7owI-O4QRrvsxCl3BJDVPj3Rzh9ks5s2IEhgaJpZM4QUUq3>
.
|
|
@DemiMarie Nothing, because websites don't use OpenGL directly nor do they have kernel access directly like Flatpaks. |
|
I thought the Chromium sandbox proxied all OpenGL access.
…On Nov 13, 2017 4:56 PM, "TingPing" ***@***.***> wrote:
@DemiMarie <https://github.com/demimarie> Nothing, because websites don't
use OpenGL directly nor do they have kernel access directly like Flatpaks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1152 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGGWB9eHSkVi-lnZSXIACKhm2xH_6-m8ks5s2LsEgaJpZM4QUUq3>
.
|
|
From https://fedoraproject.org/wiki/Changes/WorkstationOstree:
I am staying tuned 😶 |
|
@TingPing Chrome content processes cannot access OpenGL directly. All OpenGL calls are proxied through a GPU process. Flatpak should take a similar approach. |
|
@DemiMarie Chrome only runs javascript using an OpenGL subset (webgl). Running arbitrary code and proxying its GPU access is not possible. |
Any updates on this? |
|
Seconded. Flatpak is not secure without this.
As far as GPU stuff is concerned, the best answer is probably virgl if you
are less paranoid. Otherwise, the best answer is software rendering + the
QubesOS display protocol.
And most existing apps will work without this. They just need a
virtualized home directory.
On Sep 22, 2018 1:25 AM, "Matthew Harm Bekkema" <[email protected]> wrote:
@amtlib-dot-dll <https://github.com/amtlib-dot-dll>
* Make per-app xwayland possible for X apps
Any updates on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1152 (comment)>,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGGWB_Io8qPIALsT7dxN_D4_WGQBUAY6ks5udcm2gaJpZM4QUUq3>
.
|
I'm afraid not, though I'm not concerned on this since long ago |
|
May I ask why?
…On Sun, Sep 23, 2018, 8:45 AM 朝歌 ***@***.***> wrote:
@mat8913 <https://github.com/mat8913>
Any updates on this?
I'm afraid not, though I'm not concerned on this since long ago
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1152 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGGWB50fWsQ6sZtaY_ividF4IaPi3qdlks5ud4JvgaJpZM4QUUq3>
.
|
|
@DemiMarie There isn't any more information about this apart from that website 🤷♂️
|
Currently, apps can request access to (for instance) a user’s entire home directory, to a shared
/tmp, or to X11, the system message bus, or the session message bus. All of those can be used to run code with full privileges of the invoking user.This is bad! Flatpak should not allow such powerful permissions. Instead, requests for any file that doesn’t belong to the app should be forced to go through a proxy, which allows the user to select a file (and which can deny the request). There is no reasonable way for a user to accept or deny requests for X11 or the system or user message busses, so these should never be allowed – Flatpak must have a hard dependency on Wayland, or launch a subsidiary X server for each instance of each app.
This will require that applications be modified to access user files via the provided Flatpak APIs rather than standard OS APIs, but I believe the tremendous security win (essentially, being able to download any arbitrary Flatpak program and run it without worrying that it will compromise your system – a guarantee that iOS and Android have offered since the very beginning) to be more than worth it. Application developers will need to get used to a Web-style model however (where the user, not the program, controls which files are opened).
The text was updated successfully, but these errors were encountered: