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

11–20 of 136 posts

Re: First fully sandboxed Linux desktop app

#11

Post by alexlarsson »

weland wrote: post #10
alexlarsson wrote: post #7

Earlier quoted context omitted.

It all depends on what your goal is. Allowing to run VLC as a bundle with more or less full access is certainly possible. However, that is not really "sandboxed" in any fashion. For instance, once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. If we want to support the full functionallity for a media player in a sandboxed way we need to…

> Is raw audio output necessary? Why does not pulseaudio work? I don't know if this applies to VLC, too, but raw audio output (or something that isn't PulseAudio) is necessary wherever low (or at least constant) latency is required. Edit: oh - now that I look at your username, I believe congratulations are in order re. the subject of this thread :)?

PulseAudio can be very low latency. Here are some docs on how to set this up: http://www.freedesktop.org/wiki/Software/PulseAudio/Document...

That said, I don't think a video player needs low latencies. It can generally have pretty large buffers.

Re: First fully sandboxed Linux desktop app

#12

Post by agwa »

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…

Instead of sandboxing the entire app, you should use privilege separation inside VLC. Low-risk code would run in processes with higher privileges, while the high-risk code (e.g. the decoders) would run in highly sandboxed processes and communicate with the privileged processes over a simple interface. This is the approach used by security-conscious server apps (e.g. openssh, postfix, dovecot) as well as Google Chrome, and I think it has more promise than trying to sandbox entire apps. Many apps have complex access requirements (much more than the game used as an example in this blog post) and trying to sandbox them will require granting so much privilege that the sandbox becomes almost meaningless.

I'm currently working on converting a PDF viewer to use privilege separation. I'd love to see a media player use privilege separation too. Does VLC currently have pretty clear separation between its various components? Do you think it be much work to spin security-conscious parts like the decoders into separate processes?

Re: First fully sandboxed Linux desktop app

#13

Post by Torgo »

alexlarsson wrote: post #7
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…

It all depends on what your goal is. Allowing to run VLC as a bundle with more or less full access is certainly possible. However, that is not really "sandboxed" in any fashion. For instance, once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. If we want to support the full functionallity for a media player in a sandboxed way we need to…

>once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen.

Wayland fixes this.

Re: First fully sandboxed Linux desktop app

#14

Post by davidgerard »

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…

>they refuse blankly, saying that my "use case is irrelevant and dangerous".

Because it's not like anyone uses media players in the real world.

Seriously, WHAT?

Re: First fully sandboxed Linux desktop app

#15

Post by jbk »

alexlarsson wrote: post #7
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…

It all depends on what your goal is. Allowing to run VLC as a bundle with more or less full access is certainly possible. However, that is not really "sandboxed" in any fashion. For instance, once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. If we want to support the full functionallity for a media player in a sandboxed way we need to…

> It all depends on what your goal is.

Well, we've seen sandboxes on other desktop platforms (OSX, WinRT, ChromeOS), and so far, they all are horribly limiting. So, I'm making sure the same does not happen on Linux, before we get kicked out of our own platform.

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

> Raw device access will not happen by just having the app open the raw device nodes. Instead we'll have some kind of service in the session that (via user interaction or "remembered" grants from the user) virtualizes access to these things.

Well, this is a deal breaker so far. Are you going to do a pulsedvd, a pulsecd, a pulsedvb, a pulsesdi for all the access modules? Playing encrypted DVD requires direct access, as far as I know.

> For an example of the later, for webcams see the pulse-video project: https://github.com/wmanley/pulsevideo

Something using GStreamer in Vala to get indirect access to webcams? I don't see how this could even work: how do you control brightness or other webcam controls from two applications, how do you get direct H26x access with preview synchronized? (And asking someone to use a competitive project to get video input is also a bit rude, but that's beside the subject)

> Why does not pulseaudio work?

libpulse requires X, as far as I know.

> OpenGL access is supported

Through Wayland? How do I get YUV surfaces? What about overlay? What about VDPAU/VAAPI? I guess this will get a lot of improvement, because wayland, wl_scaler (et al) are very limited, so far.

We'll see how it fares, but from the past interactions, the answers were pretty dismissive; and therefore, I'm not that optimistic about the outcome.

Re: First fully sandboxed Linux desktop app

#16

Post by [deleted] »

Torgo wrote: post #13
alexlarsson wrote: post #7

Earlier quoted context omitted.

It all depends on what your goal is. Allowing to run VLC as a bundle with more or less full access is certainly possible. However, that is not really "sandboxed" in any fashion. For instance, once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. If we want to support the full functionallity for a media player in a sandboxed way we need to…

>once any client has any kind of X11 access they can snope any kind of keyboard events, including your password at the unlock screen. Wayland fixes this.

[deleted]

Re: First fully sandboxed Linux desktop app

#18

Post by jbk »

agwa wrote: post #12
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…

Instead of sandboxing the entire app, you should use privilege separation inside VLC. Low-risk code would run in processes with higher privileges, while the high-risk code (e.g. the decoders) would run in highly sandboxed processes and communicate with the privileged processes over a simple interface. This is the approach used by security-conscious server apps (e.g. openssh, postfix, dovecot) as well as Google Chrome…

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

The crashes mostly happen in protocols and demuxers, but not in decoders (a contrario from what people think).

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.

For audio output, it's not good either, although some platforms are better (pulseaudio+Kdbus might work).

Re: First fully sandboxed Linux desktop app

#19

Post by jbk »

rogerbinns wrote: post #8
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…

Note that you are requiring all of this in the same/single app. Instead it could be broken down into multiple compartmentalized apps, each doing one thing with simple permissions, and all cooperating. For example one app could do the raw device access, but have no other access including networking. Another does networking but no local access. Another is the renderer to video and audio. Another does UI etc.

And how do you share the buffers between the apps?

Re: First fully sandboxed Linux desktop app

#20

Post by jbk »

bkor wrote: post #6
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…

If you want raw access to devices, X11, etc, then it is not so simple. The media players I use talk to Pulseaudio, not directly to audio. Various of your needs go pretty much against sandboxing. It's much easier to focus first on applications instead of these needs. For instance, fully sandboxing and X11 won't work anyway. It seems pretty impossible to create something which: 1) does sandboxing 2) has no limitations…

> Is it possible to lower your requirements or change how VLC works/can do when it is sandboxed?

Maybe for some, but not for others. You really need to be able to open a file without file opener. Opening optical disks is really important too. I don't get why read-only access to a device poses so much threats but I'm probably missing something.

FYI, so far, libpulse links to x11.

Post reply on HN