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

21–30 of 136 posts

Re: First fully sandboxed Linux desktop app

#21

Post by mintplant »

_pmf_ wrote: post #9

The future is here! Maybe the lack of a heavily regulated, but ultimately non-curated aggregation of low quality application that safely do nothing has been holding back Linux on the desktop all these years. P.S.: systemd now allows logging in via your Facebook account on every machine, per default since Ubuntu Timid Tamandu!

In the light of the NSA hacking revelations, we should recognize that the systems we're using are fundamentally insecure. With Linux, we should be able to improve security while maintaining user control. I think this is a step in the right direction.

Re: First fully sandboxed Linux desktop app

#24

Post by riskable »

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! No problem, right? Wrong.

Your little web server daemon is going to run as some user. Let's say that user is root to keep things simple. So now your root user needs to spin up an X11 server for each user (so their sessions are separate). But that won't work so well because the X11 servers will all be running as the same user (root). This means that each user can mess with each other's applications, log their keystrokes, etc.

So what do you do? Well, you can just create random, one-time user accounts in /etc/passwd and spin up X11 using those accounts but now your little daemon has to run as root. Also, you now have to keep track of and maintain not just all those temporary users but all the files owned by those users. You also need to keep track of which user had what account and when (for auditing purposes). You also have to worry about UID conflicts (especially with external systems) and some other less common scenarios (e.g. LDAP integration with sudo).

Another option would be to give each user their own container and run X11 inside of that. Except now the application can't get access to OpenGL acceleration and shared memory access (so your little deamon can capture the screen) becomes complicated. Then there's the fact that if you want to give the users access to more applications those applications will need to be installed inside each user's container. You can do some tricks with mounts in order to work around that problem somewhat but it's complicated. REALLY complicated!

For now I've decided to just assume the daemon will be running as a single user (doesn't matter which one) while I work on some other things (e.g. improving audio support) but very soon I'm going to have to come back to the multi-user security problem. It's not easy to solve.

The way X11 was engineered just assumes that each user has their own processes and if you do have multiple users all their applications will be running under different accounts.

Re: First fully sandboxed Linux desktop app

#26

Post by chubot »

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)

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 time, so it seems feasible.

Also, Chrome has multiple video playing paths, including Flash, which is sandboxed, so I don't see the difference. The Flash video has to be decoded in a sandbox. I imagine HTML5 video is sandboxed somehow too.

It is very platform-specific and difficult, and performance is a prime concern, but not impossible.

Re: First fully sandboxed Linux desktop app

#27

Post by compsciphd »

grigio wrote: post #23
compsciphd wrote: post #17

This is not really true https://www.usenix.org/legacy/events/atc10/tech/full_papers/... which was turned into https://www.google.com/patents/US8589947

chroot existed before 11 mag 2010

apparently you think usenix atc is unaware of chroot as well :)

Re: First fully sandboxed Linux desktop app

#28

Post by sp332 »

jbk wrote: post #20
bkor wrote: post #6

Earlier quoted context omitted.

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.

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.

Re: First fully sandboxed Linux desktop app

#29

Post by asveikau »

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…

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

Funny story, I have never gotten pulseaudio to successfully play any audio. Every so often I read somewhere that pulse makes audio scenario xyz really easy. I try it out and I cannot get any audio samples out to the sound card, period. The only other time I hear about pulse is when I'm telling people to kill it, which ends up fixing all their audio problems. So no thanks to pulse.

Meanwhile I can't help but think that Unix already has a security model for talking to devices, it is called enforcing security at open(2). What is bad about letting an app talk to alsa if it needs audio? If you can provide an example, is that not a privilege escalation in alsa that should be fixed?

It just strikes me that your article here is a technical solution in search of a problem. Apple did sandboxing so it must be right, huh?

Post reply on HN