
First fully sandboxed Linux desktop app - matthiasv
http://blogs.gnome.org/alexl/2015/02/17/first-fully-sandboxed-linux-desktop-app/
======
jbk
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 to X11 for YUV output, or at least a direct OpenGL context,

\- access to network.

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 "use case
is irrelevant and dangerous".

I hope this will evolve (maybe it already has), but so far, it's a bit hard to
make a complete media player, tbh.

~~~
alexlarsson
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 start looking into each requirement and designing a
safe way to access each item. This is gonna be a lot of work, but I don't see
any way around that.

For your exact list:

Files access can either be granted to the app fully or partially. But we also
want some kind of file selector service that runs in the session (outside the
sandbox) that grants some kind of access to files the user chose.

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. This could be all from e.g. passing a file descriptor of the opened
dvd device to a complete replacement of the subsystem. For an example of the
later, for webcams see the pulse-video project:
[https://github.com/wmanley/pulsevideo](https://github.com/wmanley/pulsevideo)

Is raw audio output necessary? Why does not pulseaudio work?

OpenGL access is supported

Network access is (optionally, but i think this will be on for most apps)
allowed

~~~
jbk
> 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](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.

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

~~~
greggman
Maybe I'm missing it but I don't see how DRI is really sandboxing OpenGL.

Note: I helped write the OpenGL sandbox in Chrome and it's certainly possible
I don't know the details of DRI enough to understand how it sandboxes but I do
know what we had to do to sandbox OpenGL in Chrome, that includes re-writing
shaders since we can't trust the driver, clearing buffers since OpenGL doesn't
and so you can read other processes' data, and many other things and as far as
I can tell DRI isn't doing things like that.

~~~
alexlarsson
At the moment we grant all of /dev/dri, but long term we want only the render
nodes accessible. That gives us no modesetting or DRM master capabilities,
only rendering.

It is true though that the drivers could very well have leaks in them, but the
userspace sandbox is not the place to fix that, it is the drivers themselves.
The intent is for the dri driver APIs to give guarantees about client
separation, but I'm sure it needs work.

~~~
greggman
The drivers will never be fixed. Chrome doesn't trust them. It's not in their
interest to fix them since sales are determined by performance not by
security.

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

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

~~~
joelthelion
To be fair, this has exactly zero effect on the NSA hacking your machine,
especially if the hard disk firmware is compromised.

~~~
tormeh
Only if the firmware is compromised before you install the OS. It adds a
significant hurdle to any malware gaining write access to your hard drive's
firmware.

------
compsciphd
This is not really true

[https://www.usenix.org/legacy/events/atc10/tech/full_papers/...](https://www.usenix.org/legacy/events/atc10/tech/full_papers/Potter.pdf)

which was turned into

[https://www.google.com/patents/US8589947](https://www.google.com/patents/US8589947)

~~~
grigio
chroot existed before 11 mag 2010

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

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

~~~
jblow
I am not sure why Linux people tend to think this is bad. It is how you ship
robust software that doesn't break. Linux "solves" this issue by having all
kinds of things break all the time and just accepting that breakage and saying
"no really things usually work fine".

~~~
edohyiez
The main argument against this kind of bundling (apart from higher disk usage)
is about security updates of libraries. E.g. if many applications ship their
own copy of OpenSSL and another vulnerability is discovered, you have to
update every application individually. And it is unlikely that all
developers/vendors will provide such updates fast enough.

But if all applications use the same OpenSSL that is managed by dpkg+apt (or
something similar), a single update will fix all applications.

Personally, I don't think that this problem can be solved without losing the
advantages of bundling (robustness, reproducability, binary portability to
other distributions).

~~~
kayamon
Right, but there's a difference between things that the OS is expected to
provide (OpenSSL, GTK, etc) which the app should not bundle, and things like
libpng which the app basically should bundle.

e.g. Windows supplies KERNEL/USER/GDI as builtins, but doesn't supply libpng.

Pretty much the whole point of an OS is to provide a guaranteed stable base.
Anything that isn't guaranteed or stable should be bundled with the app.

~~~
dbdr
If libpng has a new vulnerability discovered, how do you make sure it is fixed
in all the apps that bundle it?

[http://www.cvedetails.com/vulnerability-
list/vendor_id-7294/...](http://www.cvedetails.com/vulnerability-
list/vendor_id-7294/Libpng.html)

------
timthelion
While I'll admit that my personal project, subuser.org isn't yet at the stage
of 100% sandboxed, this title is excedingly misleading. There are lots of
projects that have done this allready:
[http://www.jann.cc/2014/09/06/sandboxing_proprietary_applica...](http://www.jann.cc/2014/09/06/sandboxing_proprietary_applications_with_docker.html),
[https://github.com/Kagami/kagome](https://github.com/Kagami/kagome)

~~~
alexlarsson
The title is a bit hyperbolic, true. There have been various ways to try to
contain desktop apps over the years. But I wouldn't call them "apps" really,
they may get the sandboxing aspects down, but they don't have the simple-to-
install, well-integrated behaviour that you'd want for something like an "app"
system. Most of them basically run the app in its own VNC or Xserver instance,
with zero interaction with the rest of the session.

------
ndesaulniers
Sounds like a browser to me. FTFY:

* Is independent of the host distribution

* Has no access to any system or user files other than the ones from the runtime and application itself

* Has no access to any hardware devices (GL rendering supported)

* Has restricted network access

* Can’t see any other processes in the system

* Can only get input via standard APIs

* Can only show graphics via DOM/Canvas/WebGL/SVG/MathML

* Can only output audio via Audio Tags/Web Audio/MSE

* plus more sandboxing details

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

I have a guide on running accelerated GUI apps in both privileged and
unprivileged containers: [http://www.flockport.com/run-gui-apps-in-lxc-
containers](http://www.flockport.com/run-gui-apps-in-lxc-containers) and
here's one more by Stephane Graber, lead developer of LXC using only
unprivileged containers: [https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-
container...](https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/)

------
riskable
I've been working on getting web-based X11 working for a while now...

[http://youtu.be/vca13X1TpIw](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.

~~~
compsciphd
I use this all the time these days
[https://github.com/kanaka/noVNC](https://github.com/kanaka/noVNC)

related to what you are trying to do?

~~~
riskable
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).

~~~
compsciphd
yes, vnc is not made for video (or audio, but that's obvious). a decade ago
the lab I was part of was working on that issue.

[http://systems.cs.columbia.edu/projects/thinc/](http://systems.cs.columbia.edu/projects/thinc/)

maybe something here is of interest to you (code is probably way outdated
though)

------
copsarebastards
I have mixed feelings on the idea of sandboxed apps.

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.

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

------
diltonm
>> we have to use Wayland instead of X11, because X11 is impossible to secure.

Yet X11 was designed in the prime example world of a mult-user OS, UNIX. Hmm.

>> We also need to use kdbus to allow desktop integration that is properly
filtered at the kernel level.

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

~~~
edohyiez
This isn't about isolating users from each other, but isolating different
applications running as the same user from each other. X11 (and Unix itself)
was not designed to do this.

Also, kdbus has nothing to do with graphics.

------
z3t4
How hard would it be to make something like:

This program wants to access your camera, mike, //home/personal, connect to
irc://botnet.com, and install these dependencies: spyware1, 2, 3 Are you sure
you want to install/run [insert innocent program]?

I think that would be an better option then sand-boxing everything.

Is it even possible for the OS to know if a program is using the webcam?

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

------
yarrel
The cargo-culting continues.

------
ExpiredLink
Slightly off topic but what happened to the 'Android as Linux desktop'
initiatives?

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

~~~
iso8859-1
I don't think this will help you. It sounds more like you need something like
buildroot or 0install.

~~~
hitlin37
well. i want to do some testing on a legacy app. The app runs fine on old
veriosn of firefox and old OS but i want to try it on a recent distribution
and remove firefox dependancy as a next step. Isn't it fits with sandboxing
way of app development.?

------
ageofwant
Y U No Docker ?

------
grigio
better later than never

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

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

~~~
tonyedgecombe
The result is still the same though.

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

~~~
mempko
I can see this being useful for running proprietary and non free software.
However, we should strive for all software to be free software instead.
Because if I download free software, I have the community of developers to
vouch for it. If I download proprietary software, I can't really trust it.

~~~
vidarh
My answer to that is "heartbleed". It is irrelevant if you trust the
developers - sometimes those developers will make mistakes. Sometimes those
mistakes will be serious.

The less privileges your applications run with, the less likely it will be
that exploits will affect you.

