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

31–40 of 136 posts

Re: First fully sandboxed Linux desktop app

#31

Post by agwa »

jbk wrote: post #18
agwa wrote: post #12

Earlier quoted context omitted.

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

Re: First fully sandboxed Linux desktop app

#32

Post by compsciphd »

riskable wrote: post #24

I've been working on getting web-based X11 working for a while now... http://youtu.be/vca13X1TpIw It works very well but I can't release it yet because there's an underlying problem and the author of this article pointed it out very clearly: > because X11 is impossible to secure So imagine the scenario: You want to have a single server that hosts desktop environments for multiple users over the web. X11 is multi-user…

I use this all the time these days https://github.com/kanaka/noVNC

related to what you are trying to do?

Re: First fully sandboxed Linux desktop app

#33

Post by edohyiez »

mempko wrote: post #30

I think this blog post highlights my beef with going ultra secure and not trusting the user. security will stifle application innovation. Making cool things hard, and awesome things impossible.

It's not about "not trusting the user", but about the user not having to trust the author of the application.

Re: First fully sandboxed Linux desktop app

#34

Post by asveikau »

sp332 wrote: post #28
jbk wrote: post #20

Earlier quoted context omitted.

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

Low-level access to a device would let you read data from files that you don't have permission to read at the filesystem level.

You can set different permissions for different devices, you are aware of that right? I can say my DVD drive is readable by gid x, but not the partitions on my hard disk... This is already what Linux distros are doing.

Re: First fully sandboxed Linux desktop app

#35

Post by tonyedgecombe »

edohyiez wrote: post #33
mempko wrote: post #30

I think this blog post highlights my beef with going ultra secure and not trusting the user. security will stifle application innovation. Making cool things hard, and awesome things impossible.

It's not about "not trusting the user", but about the user not having to trust the author of the application.

The result is still the same though.

Re: First fully sandboxed Linux desktop app

#36

Post by edohyiez »

tonyedgecombe wrote: post #35
edohyiez wrote: post #33

Earlier quoted context omitted.

It's not about "not trusting the user", but about the user not having to trust the author of the application.

The result is still the same though.

No. Why would it? The user can still grant full access to the machine to applications they trust (like they do now). In fact, the traditional Unix security model (root vs. regular users) was about "not trusting the user" and securing the machine from the user. This "new" kind of sandbox is about the user being able to apply different levels of trust to different applications.

Re: First fully sandboxed Linux desktop app

#37

Post by upofadown »

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…

Why would you want to sandbox an open source program like VLC? This sort of thing is mostly useful to allow the running of proprietary binaries that could be hostile in some way. You are not going to care that much if you can trust a program not to attack other programs.

Re: First fully sandboxed Linux desktop app

#38

Post by edohyiez »

asveikau wrote: post #34
sp332 wrote: post #28

Earlier quoted context omitted.

Low-level access to a device would let you read data from files that you don't have permission to read at the filesystem level.

You can set different permissions for different devices, you are aware of that right? I can say my DVD drive is readable by gid x, but not the partitions on my hard disk... This is already what Linux distros are doing.

Then the media player can read every DVD you put into your drive as long as its running. So you always have to close the media player before inserting a DVD containing private files. That probably isn't that important for DVDs, but for other devices (e.g. microphone, webcam) it certainly is.

Re: First fully sandboxed Linux desktop app

#39

Post by alexlarsson »

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

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

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

Well, its hard to say that as this kind of stuff is not designed yet. Better to say that the requirements of VLC on the design of this are more complex than just the "allow access to single-picked-file" semantics. Hopefully we can take this into account when we look into the details here.

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

Some of these need not necessarily be as complex as you imagine though. They could very well be some kind of thin service that enumerates the real devices and hands over the opened FD to your app after having verified that it is allowed.

> libpulse requires X, as far as I know.

Libpulse can optionally be built with X, but this is really only used to read back the pulse socket name from the x root property. It works just fine without X (witness the non-X, but pulseaudio using demo in the blog post for instance).

OpenGL access is via DRI, but yeah, output to the screen will have to happen via wayland. That could use subsurfaces with YUV surfaces, and it is then up to the compositor to use overlays if possible (i know weston does this for instance).

For VDPAU etc, i don't really know.

Re: First fully sandboxed Linux desktop app

#40

Post by rogerbinns »

jbk wrote: post #19
rogerbinns wrote: post #8

Earlier quoted context omitted.

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?

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.
Post reply on HN