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

81–90 of 136 posts

Re: First fully sandboxed Linux desktop app

#81

Post by em3rgent0rdr »

jbk wrote: post #2

It's really nice to see that happening, but every time I raised the subject with the Gnome team to see how we could run VLC in it, it's a no-go. Indeed, for a complete media player, I need: - access to files not directly opened by the user (playlists, MKV, DCP, MXF), - access (and unique probably) to raw devices read-only (DVD, AudioCD, Blu-Rays, webcams-v4l2, SDI, DVB), - direct access to raw audio output, - access…

for such security, you should use something like Qubes OS (https://qubes-os.org/) which uses Xen to sandbox apps into different domains (VMs), and keeps the networking stack in a seperate VM, disk storage in a seperate VM, DE in a seperate VM, etc.

Re: First fully sandboxed Linux desktop app

#83

Post by comex »

jbk wrote: post #80
alexlarsson wrote: post #76

Earlier quoted context omitted.

Can you not use dma-buf and EXT_image_dma_buf_import?

Maybe, but that's quite not portable, and driver specific, AFAIK.

Forgive me for a short rant, but this sort of thing is one reason I think other kernels should look at OS X's virtual memory interface for inspiration. There, you can always share any existing mapped page with another process, regardless of how it was allocated. Usually useful because it reduces the need to redo the way you allocate some (regular) memory just because you want to use it a certain way (sharing), but it works with driver-mapped pages too.

Re: First fully sandboxed Linux desktop app

#84

Post by alexlarsson »

comex wrote: post #83
jbk wrote: post #80

Earlier quoted context omitted.

Maybe, but that's quite not portable, and driver specific, AFAIK.

Forgive me for a short rant, but this sort of thing is one reason I think other kernels should look at OS X's virtual memory interface for inspiration. There, you can always share any existing mapped page with another process, regardless of how it was allocated. Usually useful because it reduces the need to redo the way you allocate some (regular) memory just because you want to use it a certain way (sharing), but it…

Sharing a normal memory mapping is not necessarily what is required here though. What you want is to share the same GPU-side memory buffer between two processes. It may not even be mappable to cpu side memory.

Re: First fully sandboxed Linux desktop app

#85

Post by rogerbinns »

jbk wrote: post #75
rogerbinns wrote: post #40

Earlier quoted context omitted.

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.

Are you saying it is completely impossible? Or that they haven't done it yet? The former would be a big problem, and the latter is just about the right apis, driver models etc.

Re: First fully sandboxed Linux desktop app

#86

Post by ndesaulniers »

Sounds like a browser to me. FTFY:

* Is independent of the host distribution

* Has no access to any system or user files other than the ones from the runtime and application itself

* Has no access to any hardware devices (GL rendering supported)

* Has restricted network access

* Can’t see any other processes in the system

* Can only get input via standard APIs

* Can only show graphics via DOM/Canvas/WebGL/SVG/MathML

* Can only output audio via Audio Tags/Web Audio/MSE

* plus more sandboxing details

Re: First fully sandboxed Linux desktop app

#87

Post by comex »

alexlarsson wrote: post #84
comex wrote: post #83

Earlier quoted context omitted.

Forgive me for a short rant, but this sort of thing is one reason I think other kernels should look at OS X's virtual memory interface for inspiration. There, you can always share any existing mapped page with another process, regardless of how it was allocated. Usually useful because it reduces the need to redo the way you allocate some (regular) memory just because you want to use it a certain way (sharing), but it…

Sharing a normal memory mapping is not necessarily what is required here though. What you want is to share the same GPU-side memory buffer between two processes. It may not even be mappable to cpu side memory.

If it's mapped into the CPU address space, then it can be shared. If not, then there is a copy going on and you may as well just do it in the non-sandboxed process, no?

Re: First fully sandboxed Linux desktop app

#88

Post by copsarebastards »

I have mixed feelings on the idea of sandboxed apps.

On the one hand, I want to be able to run untrusted applications safely. And in a larger sense, I think that it might be a hopeless endeavor to try to get users to only run trustworthy applications on their machines.

On the other hand, I want to have full access to my system, and sometimes that means having full access to it through applications (jbk's VLC use case is a good example of that). And sandboxes are far from perfect (this may improve, but right now existing sandboxes still have lots of holes). Sandboxes may be just security theater at this point (although as I said, this might change).

Re: First fully sandboxed Linux desktop app

#89

Post by gknoy »

jbk wrote: post #70
MaulingMonkey wrote: post #60

Earlier quoted context omitted.

>> kind of file selector service that runs in the session (outside the sandbox) that grants some kind of access to files the user chose. > This is not enough, as explained above. If the file chooser is powerful enough, couldn't it be? I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as…

> If the file chooser is powerful enough, couldn't it be? Experience from OS X and WinRT is that they aren't powerful. > I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 What about mkv linked files or .mpc lossless complements? Or cue/bin complements? What about m3u that have mp3, ogg and flac interleaved? It's not that simple.

Then you'd grant access to ~/my-media-collection/ , or to each of the filetypes in your collection.

Re: First fully sandboxed Linux desktop app

#90

Post by bitL »

So a seriously limiting concept from mobile/web world is making it into Linux as well? Soon we won't be able to do anything with our computers, but we will be "perfectly safe". Everything I dislike about iOS is now becoming mainstream. Disclaimer - I wrote a book about cryptology including TPM, secure boot loaders, PKI, etc. another one about 3D graphics and am very aware of the issues and trade offs. But sandboxing is a charming but ultimately silly solution that ultimately removes any capability from the hands of users and slows everything down - it already negatively affects graphics performance of browsers (tainted canvas anyone? how long would WebGL shader hack to bypass this work until we are forced to accept 100 pixels/second performance with sandboxing?). There are even rumors that Skylake is going to be slower and more power hungry than Broadwell due to SGX (we will see soon I guess). Is it really worth it?
Post reply on HN