Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First fully sandboxed Linux desktop app

blogs.gnome.org

Post reply on HN
Print view View original

71–80 of 136 posts

Re: First fully sandboxed Linux desktop app

#71

Post by jbk »

chubot wrote: post #26
jbk wrote: post #18

Earlier quoted context omitted.

It's a good question. But hard. > Does VLC currently have pretty clear separation between its various components? Very clear separation. One of the best, tbh. > Do you think it be much work to spin security-conscious parts like the decoders into separate processes? Extremely difficult. We've thought about it. For a video player the 3 parts that are sensitive, are protocols (file, http), demuxers (mkv, avi) and decode…

The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) Why not used shared memory? I believe that's what Chrome uses for its rendering buffers. The renderer is sandboxed and shares buffers with the X11 process. EDIT, used to use: https://codereview.chromium.org/298443002/ Still, it appears it used this method for a long ti…

> Why not used shared memory?

Because this is not normal shared memory, this is GPU shared memory. This is hard to port.

Re: First fully sandboxed Linux desktop app

#72

Post by jbk »

alexlarsson wrote: post #44
jbk wrote: post #18

Earlier quoted context omitted.

It's a good question. But hard. > Does VLC currently have pretty clear separation between its various components? Very clear separation. One of the best, tbh. > Do you think it be much work to spin security-conscious parts like the decoders into separate processes? Extremely difficult. We've thought about it. For a video player the 3 parts that are sensitive, are protocols (file, http), demuxers (mkv, avi) and decode…

> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. And video output are usually with very high access in the kernels. Moreover video outputs are almost necessarily in the process with the UI thread. Did you look into the new memfd support in the kernels? Seems like this is a pretty cool way…

> For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work?

This is not portable, but this is a possible solution for Linux.

But this is far from being ready, which is one of my main point :)

Re: First fully sandboxed Linux desktop app

#73

Post by jbk »

agwa wrote: post #31
jbk wrote: post #18

Earlier quoted context omitted.

It's a good question. But hard. > Does VLC currently have pretty clear separation between its various components? Very clear separation. One of the best, tbh. > Do you think it be much work to spin security-conscious parts like the decoders into separate processes? Extremely difficult. We've thought about it. For a video player the 3 parts that are sensitive, are protocols (file, http), demuxers (mkv, avi) and decode…

> The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) and for hardware decoders. I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing? In any case, it makes me really happy to know that you've thought about this!

> I was afraid that this was the case. Might shared memory be a viable solution to buffer sharing?

It's GPU allocated memory, so not so sure.

> In any case, it makes me really happy to know that you've thought about this!

If you have ideas, we'd love to work on it, seriously.

Re: First fully sandboxed Linux desktop app

#74

Post by jbk »

Estragon wrote: post #47
jbk wrote: post #18

Earlier quoted context omitted.

It's a good question. But hard. > Does VLC currently have pretty clear separation between its various components? Very clear separation. One of the best, tbh. > Do you think it be much work to spin security-conscious parts like the decoders into separate processes? Extremely difficult. We've thought about it. For a video player the 3 parts that are sensitive, are protocols (file, http), demuxers (mkv, avi) and decode…

I'm curious, have there been bugs in VLC which would allow arbitrary code execution on linux? What about the video player in google chrome?

Yes for both.

Re: First fully sandboxed Linux desktop app

#75

Post by jbk »

rogerbinns wrote: post #40
jbk wrote: post #19

Earlier quoted context omitted.

And how do you share the buffers between the apps?

The desktop environment already has to provide a means of interprocess/component communication, so it gets solved there. You can already see something similar in Chrome where functionality like rendering is done in separate processes.

No it has not. 0-copy shared buffer don't exist yet for most video usecases.

Re: First fully sandboxed Linux desktop app

#76

Post by alexlarsson »

jbk wrote: post #71
chubot wrote: post #26

Earlier quoted context omitted.

The main issue is that the video decoder MUST be in the same process than the video output, for performance reasons (buffer sharing: memcpy is murder) Why not used shared memory? I believe that's what Chrome uses for its rendering buffers. The renderer is sandboxed and shares buffers with the X11 process. EDIT, used to use: https://codereview.chromium.org/298443002/ Still, it appears it used this method for a long ti…

> Why not used shared memory? Because this is not normal shared memory, this is GPU shared memory. This is hard to port.

Can you not use dma-buf and EXT_image_dma_buf_import?

Re: First fully sandboxed Linux desktop app

#77

Post by davexunit »

gegenschall wrote: post #50
davexunit wrote: post #25

Do these sandboxes requiring bundling all the necessary dependencies a la Windows applications? I sure hope not.

In my understanding you can just (read-only) bind-mount the necessary libraries into the sandbox, ship your own, or do a combination of the former two.

bind-mounting and/or symlinks are good ways to go. That way there isn't unnecessary duplication.

Re: First fully sandboxed Linux desktop app

#78

Post by davexunit »

jblow wrote: post #55
davexunit wrote: post #25

Do these sandboxes requiring bundling all the necessary dependencies a la Windows applications? I sure hope not.

I am not sure why Linux people tend to think this is bad. It is how you ship robust software that doesn't break. Linux "solves" this issue by having all kinds of things break all the time and just accepting that breakage and saying "no really things usually work fine".

>It is how you ship robust software that doesn't break.

It's how you ship 1000 different versions of the same library and have no idea what to do when they need to be upgraded. It's just a terrible way to manage a system. Easier doesn't mean better.

Re: First fully sandboxed Linux desktop app

#79

Post by edohyiez »

cplease wrote: post #63
edohyiez wrote: post #46

Earlier quoted context omitted.

> The average Linux desktop user has legitimate reasons they don't want to sandbox any given desktop app to this extent. Could you expand on that?

It depends on what you mean by "sandboxing" and "app." But basically, with a browser or mobile app, there's a limited number of functions that you may want to permit an app to access, and it's okay to isolate the rest of the app to its own little world. With desktop apps, you generally want to be able to use apply them broadly to all your user data, or you will quickly be frustrated with them. Deeper-level sandboxing…

I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect.

Of course it's important that the sandbox doesn't frustrate you or lead you to blindly click "Allow" all the time. It would obviously be bad if you get a dialog asking "Application X wants to open file Y. Allow/Deny" whenever an app attemts to access a file. But I don't think that that's the only way to design a sandbox.

For the simple case of opening a file with an app, it could be enough if the app calls a trusted file-chooser outside the sandbox which then returns an opened fd to the file the user chose. Then the user wouldn't even notice that there was a sandbox. Of course that's not enough for all usecases (see some other comments from jbk about VLC).

Re: First fully sandboxed Linux desktop app

#80

Post by jbk »

alexlarsson wrote: post #76
jbk wrote: post #71

Earlier quoted context omitted.

> Why not used shared memory? Because this is not normal shared memory, this is GPU shared memory. This is hard to port.

Can you not use dma-buf and EXT_image_dma_buf_import?

Maybe, but that's quite not portable, and driver specific, AFAIK.
Post reply on HN