First fully sandboxed Linux desktop app

It&#x27;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&#x27;s a no-go.<p>Indeed, for a complete media player, I need:<p>- access to files not directly opened by the user (playlists, MKV, DCP, MXF),<p>- access (and unique probably) to raw devices read-only (DVD, AudioCD, Blu-Rays, webcams-v4l2, SDI, DVB),<p>- direct access to raw audio output,<p>- access to X11 for YUV output, or at least a direct OpenGL context,<p>- access to network.<p>For access to files and network, there seemed to be a solution with a manifest to get $home access; for audio, a solution might come with kdbus and pulseaudio; but for the others, they refuse blankly, saying that my &quot;use case is irrelevant and dangerous&quot;.<p>I hope this will evolve (maybe it already has), but so far, it&#x27;s a bit hard to make a complete media player, tbh.

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>P.S.: systemd now allows logging in via your Facebook account on every machine, per default since Ubuntu Timid Tamandu!

This is not really true<p><a href="https://www.usenix.org/legacy/events/atc10/tech/full_papers/Potter.pdf" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;legacy&#x2F;events&#x2F;atc10&#x2F;tech&#x2F;full_papers&#x2F;...</a><p>which was turned into<p><a href="https://www.google.com/patents/US8589947" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;patents&#x2F;US8589947</a>

Do these sandboxes requiring bundling all the necessary dependencies a la Windows applications? I sure hope not.

While I&#x27;ll admit that my personal project, subuser.org isn&#x27;t yet at the stage of 100% sandboxed, this title is excedingly misleading. There are lots of projects that have done this allready: <a href="http://www.jann.cc/2014/09/06/sandboxing_proprietary_applications_with_docker.html" rel="nofollow">http:&#x2F;&#x2F;www.jann.cc&#x2F;2014&#x2F;09&#x2F;06&#x2F;sandboxing_proprietary_applica...</a>, <a href="https://github.com/Kagami/kagome" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Kagami&#x2F;kagome</a>

Sounds like a browser to me. FTFY:<p>* Is independent of the host distribution<p>* Has no access to any system or user files other than the ones from the runtime and application itself<p>* Has no access to any hardware devices (GL rendering supported)<p>* Has restricted network access<p>* Can’t see any other processes in the system<p>* Can only get input via standard APIs<p>* Can only show graphics via DOM&#x2F;Canvas&#x2F;WebGL&#x2F;SVG&#x2F;MathML<p>* Can only output audio via Audio Tags&#x2F;Web Audio&#x2F;MSE<p>* plus more sandboxing details

This is actually quite similar to using LXC containers to run GUI apps. Something like Wine would be a good candidate to run in a container, perhaps others too. And you can use both privileged and unprivileged containers for this.<p>I have a guide on running accelerated GUI apps in both privileged and unprivileged containers: <a href="http://www.flockport.com/run-gui-apps-in-lxc-containers" rel="nofollow">http:&#x2F;&#x2F;www.flockport.com&#x2F;run-gui-apps-in-lxc-containers</a> and here&#x27;s one more by Stephane Graber, lead developer of LXC using only unprivileged containers: <a href="https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/" rel="nofollow">https:&#x2F;&#x2F;www.stgraber.org&#x2F;2014&#x2F;02&#x2F;09&#x2F;lxc-1-0-gui-in-container...</a>

I&#x27;ve been working on getting web-based X11 working for a while now...<p><a href="http://youtu.be/vca13X1TpIw" rel="nofollow">http:&#x2F;&#x2F;youtu.be&#x2F;vca13X1TpIw</a><p>It works very well but I can&#x27;t release it yet because there&#x27;s an underlying problem and the author of this article pointed it out very clearly:<p>&gt; because X11 is impossible to secure<p>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.<p>Your little web server daemon is going to run as some user. Let&#x27;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&#x27;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&#x27;s applications, log their keystrokes, etc.<p>So what do you do? Well, you can just create random, one-time user accounts in &#x2F;etc&#x2F;passwd and spin up X11 using those accounts but now your little daemon <i>has</i> 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).<p>Another option would be to give each user their own container and run X11 inside of that. Except now the application can&#x27;t get access to OpenGL acceleration and shared memory access (so your little deamon can capture the screen) becomes complicated. Then there&#x27;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&#x27;s container. You can do some tricks with mounts in order to work around that problem somewhat but it&#x27;s complicated. REALLY complicated!<p>For now I&#x27;ve decided to just assume the daemon will be running as a single user (doesn&#x27;t matter which one) while I work on some other things (e.g. improving audio support) but very soon I&#x27;m going to have to come back to the multi-user security problem. It&#x27;s not easy to solve.<p>The way X11 was engineered just assumes that each user has their own processes and if you <i>do</i> have multiple users all their applications will be running under different accounts.

I have mixed feelings on the idea of sandboxed apps.<p>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.<p>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&#x27;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).

&gt;&gt; we have to use Wayland instead of X11, because X11 is impossible to secure.<p>Yet X11 was designed in the prime example world of a mult-user OS, UNIX. Hmm.<p>&gt;&gt; We also need to use kdbus to allow desktop integration that is properly filtered at the kernel level.<p>Didn&#x27;t I read an article on HN recently talking about a vulnerability in Windows and the subject of too close a relationship between the kernel and the end user graphics came up?

How hard would it be to make something like:<p>This program wants to access your camera, mike, &#x2F;&#x2F;home&#x2F;personal, connect to irc:&#x2F;&#x2F;botnet.com, and install these dependencies: spyware1, 2, 3 Are you sure you want to install&#x2F;run [insert innocent program]?<p>I think that would be an better option then sand-boxing everything.<p>Is it even possible for the OS to know if a program is using the webcam?

So a seriously limiting concept from mobile&#x2F;web world is making it into Linux as well? Soon we won&#x27;t be able to do anything with our computers, but we will be &quot;perfectly safe&quot;. 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&#x2F;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?

The cargo-culting continues.

Slightly off topic but what happened to the &#x27;Android as Linux desktop&#x27; initiatives?

want this on embedded devices...bundling apps on embedded linux is real pain.

Y U No Docker ?

better later than never

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