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

41–50 of 136 posts

Re: First fully sandboxed Linux desktop app

#41

Post by alexlarsson »

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

> 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 Is this true? Can you provide a proof of concept that can attack xscreensaver in this way? I was not under the impression that xscreensaver in particular is vulnerable to such an attack. I would like to see the code. > Is raw audio output necessary? Why does not pulseaudi…

> Is this true? Can you provide a proof of concept that can attack xscreensaver in this way?

I believe this should work: https://github.com/magcius/keylog

> What is bad about letting an app talk to alsa if it needs audio?

In general, audio output is not really a problem. However, input is much more problematic. For instance, your app could listen on your microphones and send the data over the network. Permissions on the audio device doesn't work here, especially considering that such permissions are per-user, not per-app.

Overall the security model in unix is pretty shit for the desktop. Its all about protecting root or other users from the user. However, if I'm on a single user laptop that is not overly interesting. The much more interesting part is protecting the user from the system. For instance by being able to run a game without it ever having the possibility of reading my personal email or web history.

Re: First fully sandboxed Linux desktop app

#42

Post by riskable »

alexlarsson wrote: post #11
weland wrote: post #10

Earlier quoted context omitted.

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

Just to clarify: No one cares if a video player has low-latency audio as long as the audio latency matches the video latency. As in, it totally sucks when the words coming out of an actor's mouth don't line up with the audio.

The only place where low-latency matters is real-time encoding situations. For example, video conferencing, composing music, streaming things live, etc but even in those situations "low" is a relative term. Low-latency video conferencing is anything under 200-500ms (depending on who you ask). Low-latency music composition is <20ms (again, depending on who you ask).

Re: First fully sandboxed Linux desktop app

#43

Post by cplease »

upofadown wrote: post #37
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.

Non "hostile," as you put it, software still has bugs. Attackers can use malicious inputs to exploit buggy software.

Unless you personally built software from trusted source with a trusted toolchain, or reverse-engineered and inspected the binary package you are installing, you have no more confidence that your installed binary package is not malicious than any proprietary binary blob. Even presuming the maintainer and packager is not malicious (and why would you trust a random open source maintainer more than a random proprietary maintainer?), there have been cases in the past where repositories have compromised and with malicious packages inserted. These are just the ones we know about. Signatures help but don't solve anything; especially with distributed projects, keys can be compromised in any number of ways. And don't help with malicious actors.

That said, I don't see sandboxing Linux apps as particularly revolutionary. Users, ACLs, and chroots have been around for ages. While not especially sugary, they are pretty effective. For full-on app sandboxing, Android is Linux, and they've been doing this since 2008. The average Linux desktop user has legitimate reasons they don't want to sandbox any given desktop app to this extent. On the server side, "sandboxing" in the form of "separation of privileges" has been standard best practice in the UNIX realm as long as Richard Stallman's beard. This is just not particularly interesting. More interesting to me is what has been done for sandboxing in the browser, most especially Chrome.

Re: First fully sandboxed Linux desktop app

#44

Post by alexlarsson »

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. 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 to do process splitting while sharing memory in a "safe" way. (i.e. the recieving side can guarantee that the sending side is not playing silly-buggers with the buffers while you read them).

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

Re: First fully sandboxed Linux desktop app

#45

Post by riskable »

upofadown wrote: post #37
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.

Don't think of it like, "I need to protect against hacking" think of it like, "I need to make sure processes cannot control each other unless explicitly allowed to do so."

Hypothetical: A vulnerability in Chrome could allow a remote attacker the ability to read/write arbitrary files on your filesystem. /tmp/.X11-unix/X0 for example. This could let them cause all sorts of havoc on your X11 display including controlling/compromising other running programs (and capturing your keystrokes).

If Chrome were sandboxed as described in the article such an attack would not be possible without first breaking out of the sandbox.

Re: First fully sandboxed Linux desktop app

#46

Post by edohyiez »

cplease wrote: post #43
upofadown wrote: post #37

Earlier quoted context omitted.

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.

Non "hostile," as you put it, software still has bugs. Attackers can use malicious inputs to exploit buggy software. Unless you personally built software from trusted source with a trusted toolchain, or reverse-engineered and inspected the binary package you are installing, you have no more confidence that your installed binary package is not malicious than any proprietary binary blob. Even presuming the maintainer a…

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

Re: First fully sandboxed Linux desktop app

#47

Post by Estragon »

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…

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?

Re: First fully sandboxed Linux desktop app

#48

Post by riskable »

compsciphd wrote: post #32
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?

noVNC is similar to what I'm working on, yes. Except it implements the VNC protocol in JavaScript which isn't the greatest when it comes to bandwidth efficiency. It's also not very flexible; it only works when sharing an entire desktop (not individual applications or windows).

As an example of the efficiency difference, when viewing an entire desktop with a single terminal application running 'top' Gate One used up 1/10th the amount of bandwidth as noVNC when I last performed benchmarking (I had them both displaying the same exact desktop; both Gate One and novnc running simultaneously).

Also, noVNC CPU utilization goes through the roof if you try to do something like play back a video. When playing back a video inside Gate One the gateone.py process only eats up about 8% of a single core of my laptop's i7 (4th gen). That's with loads of debugging enabled (I tested it just now with SMPlayer playing Big Buck Bunny somewhere at ~1024x768 resolution).

My benchmark goal is to be able to play Minecraft @30fps (~1024x768) remotely using an AWS/Rackspace/OpenStack server. I've already achieved that except the audio delay sucks (~2 seconds) so that's what I'm currently working on (had to write my own Opus/WebM audio encoder).

Re: First fully sandboxed Linux desktop app

#49

Post by weland »

alexlarsson wrote: post #11
weland wrote: post #10

Earlier quoted context omitted.

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

I think VLC also does recording, but I'm certainly in no position to comment on it. I'm not familiar with their codebase and I don't want to lie :).

I don't know what PulseAudio considers "very low latency" and there aren't any numbers on that page to indicate it, but in my experience, PA's best latency possibilities are about an order of magnitude away from being useful for any kind of hardcore real-time processing. This isn't a problem as far as PA is concerned since it's not what it was conceived for, but it won't cut it for applications which need that kind of capability.

PA also doesn't really provide latency guarantees, either. In fact, it's mentioned on that page:

> So in summary: tell PA what latency you want, but program defensively so that you can deal with getting both lower or higher measured latencies.

I don't know if that has improved though. The last time I had to poke PulseAudio was a few months before that page's "Last Edited" timestamp.

Edit: For what it's worth: I never managed to get PA to consistently keep latency below 25-30 ms, which is at least 10-15 ms away from being adequate for real-time audio processing. I guess it is a cornercase though, and probably outside the Gnome project's interests. Reading the other comments in this thread, I assume VLC's problems with PA aren't related to latency.

Re: First fully sandboxed Linux desktop app

#50

Post by gegenschall »

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