14 ms·

First fully sandboxed Linux desktop app

276 points by matthiasv 12y ago

jbk 12y ago
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.
- thanksgiving 12y ago
  How do they expect you to access the network? Can a web browser or an FTP client be sand boxed in the current scheme?
  - jbk 12y ago
    So far, I am not sure, but I think a flag in the manifest will allow a pure networking access ("Use the host network namespace").
- bkor 12y ago
  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 on what an application can do Edit: What I meant is: Is it possible to lower your requirements or change how VLC works/can do when it is sandboxed?
  - jbk 12y ago
    > 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.
    - sp332 12y ago
      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.
      - asveikau 12y ago
        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.
        edohyiez 12y ago
        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.
    - tormeh 12y ago
      >You really need to be able to open a file without file opener What if you had read/write access to /home/user/music and /home/user/video ? Once we start adding blanket access like this we would probably need to add a /home/user/secret folder that no application can access unless invited to a specific file by a file opener.
- alexlarsson 12y ago
  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
  - weland 12y ago
    > 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 :)?
    - alexlarsson 12y ago
      PulseAudio can be very low latency. Here are some docs on how to set this up: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LatencyControl/ 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.
- rogerbinns 12y ago
  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.
  - jbk 12y ago
    And how do you share the buffers between the apps?
    - rogerbinns 12y ago
      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.
      - jbk 12y ago
        No it has not. 0-copy shared buffer don't exist yet for most video usecases.
        rogerbinns 12y ago
        Are you saying it is completely impossible? Or that they haven't done it yet? The former would be a big problem, and the latter is just about the right apis, driver models etc.
        jbk 12y ago
        > Are you saying it is completely impossible? Nothing is impossible, this is software. But it's far far far from being ready.
- agwa 12y ago
  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, and I think it has more promise than trying to sandbox entire apps. Many apps have complex access requirements (much more than the game used as an example in this blog post) and trying to sandbox them will require granting so much privilege that the sandbox becomes almost meaningless. I'm currently working on converting a PDF viewer to use privilege separation. I'd love to see a media player use privilege separation too. Does VLC currently have pretty clear separation between its various components? Do you think it be much work to spin security-conscious parts like the decoders into separate processes?
  - jbk 12y ago
    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 decoders. The crashes mostly happen in protocols and demuxers, but not in decoders (a contrario from what people think). 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. For audio output, it's not good either, although some platforms are better (pulseaudio+Kdbus might work).
    - chubot 12y ago
      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/ 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.
- davidgerard 12y ago
  >they refuse blankly, saying that my "use case is irrelevant and dangerous". Because it's not like anyone uses media players in the real world. Seriously, WHAT?
- upofadown 12y ago
  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.
  - cplease 12y ago
    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.
    - edohyiez 12y ago
      > 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?
      - cplease 12y ago
        It depends on what you mean by "sandboxing" and "app." But basically, with a browser or mobile app, there's a limited number of functions that you may want to permit an app to access, and it's okay to isolate the rest of the app to its own little world. With desktop apps, you generally want to be able to use apply them broadly to all your user data, or you will quickly be frustrated with them. Deeper-level sandboxing of splitting the app up into bipartite high and low-security/complexity components, as with the Chrome browser, requires a lot of engineering for the particular application and can't simply be dropped in place on a given off-the-shelf Linux app. Coarser-level application-specific permissions in the form of AppArmor profiles, installing daemons as their own users with chroots etc, is already available and deployed. The technology to go further with it is already there.
- zanny 12y ago
  With Wayland and dbus and all the techs going into a modern Linux desktop, it is probably very doable to prompt users when a program tries to open a file with a simple "Application X wants to open file Y in location Z, let it? Yes / No / Allow for all contents of Z / Allow All Locations". That would be a misnomer, because "important" file locations like ~/.config, ~/.share, etc would always prompt user acknowledgement when a program tries to open something in those and it is not the originator program (ie, VLC can open something like ~/.config/vlc or ~/.share/vlc, but if it tried to open ~/.config/mplayer or ~/.share/mplayer you would get a prompt notification of it. > access (and unique probably) to raw devices read-only I don't think this is hard at all, device permissions are something that mostly already works. Just say "App X wants to access device Y, allow? Yes / No / Always". With good package management and distributors, you could have most of these "prompts" configured with sane defaults so you don't get spam when VLC opens files - the distro can just trust VLC in ~/Music and ~/Video all the time, and any user made directories, so just give it access everywhere except the config and share dirs, so on and so forth. When you install something it would make sense to tell users what it uses in the same way Android does upon installation, and if it tries to access something post-install you get a dialog about it (ie, VLC could say at install it uses the network, or it could ask at runtime if it tries to access the network). Why would VLC need raw audio out? Route through pulseaudio, nobody should be opening raw audio devices anymore unless you are Ardour. I think the real problem is nobody gives a shit about desktop security. I mean I run Archlinux where there isn't a single working MAC solution that does not require days of prep work. But having delved a lot into Mac and such, I have no faith in Apparmor or SELinux when PAX and Grsec is doing a much better job and nobody is using it. And they all have holes somewhere, either they don't have fine grained device permissions, or lack tunables, or don't harden the kernel enough to avoid simple exploits. Its a mess nobody is really trying to solve upstream of security implementations and distros are doing a half assed job about it across the board.
- em3rgent0rdr 12y ago
  for such security, you should use something like Qubes OS (https://qubes-os.org/ https://qubes-os.org/) which uses Xen to sandbox apps into different domains (VMs), and keeps the networking stack in a seperate VM, disk storage in a seperate VM, DE in a seperate VM, etc.
- tracker1 12y ago
  what's wrong with having a service layer that isn't sandboxed, and an application layer that is? What's stopping you from running your filesystem and network requests through a local service... you can sandbox all the rendering and other access, and tighten controls on your service interface.
- deleted 12y ago
  [deleted]
- digi_owl 12y ago
  Yeah, if this sandboxing is anything like the Storage Access Framework that Google introduced in Android 4.4, i'll pass...
alexkudryashkin 12y ago
http://i3.kym-cdn.com/photos/images/facebook/000/731/143/3e3.jpg http://i3.kym-cdn.com/photos/images/facebook/000/731/143/3e3...
_pmf_ 12y ago
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 12y ago
  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 12y ago
    To be fair, this has exactly zero effect on the NSA hacking your machine, especially if the hard disk firmware is compromised.
    - tormeh 12y ago
      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 12y ago
This is not really true https://www.usenix.org/legacy/events/atc10/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/events/atc10/tech/full_papers/... which was turned into https://www.google.com/patents/US8589947 https://www.google.com/patents/US8589947
- grigio 12y ago
  chroot existed before 11 mag 2010
  - compsciphd 12y ago
    apparently you think usenix atc is unaware of chroot as well :)
grigio 12y ago
better later than never
riskable 12y ago
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 12y ago
  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?
davexunit 12y ago
Do these sandboxes requiring bundling all the necessary dependencies a la Windows applications? I sure hope not.
- gegenschall 12y ago
  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.
  - davexunit 12y ago
    bind-mounting and/or symlinks are good ways to go. That way there isn't unnecessary duplication.
- jblow 12y ago
  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 12y ago
    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 12y ago
      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.
mempko 12y ago
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 12y ago
  It's not about "not trusting the user", but about the user not having to trust the author of the application.
  - tonyedgecombe 12y ago
    The result is still the same though.
    - edohyiez 12y ago
      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 12y ago
        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 12y ago
        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.
hitlin37 12y ago
want this on embedded devices...bundling apps on embedded linux is real pain.
- iso8859-1 12y ago
  I don't think this will help you. It sounds more like you need something like buildroot or 0install.
  - hitlin37 12y ago
    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.?
ndesaulniers 12y ago
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
copsarebastards 12y ago
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).
bitL 12y ago
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?
tobbyb 12y ago
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-containers/ https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-container...
timthelion 12y ago
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_applications_with_docker.html http://www.jann.cc/2014/09/06/sandboxing_proprietary_applica..., https://github.com/Kagami/kagome https://github.com/Kagami/kagome
- alexlarsson 12y ago
  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.
ageofwant 12y ago
Y U No Docker ?
yarrel 12y ago
The cargo-culting continues.
diltonm 12y ago
>> 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 12y ago
  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 12y ago
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?
ExpiredLink 12y ago
Slightly off topic but what happened to the 'Android as Linux desktop' initiatives?

276 points by matthiasv 12y ago

jbk 12y ago

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.

thanksgiving 12y ago
How do they expect you to access the network? Can a web browser or an FTP client be sand boxed in the current scheme?
- jbk 12y ago
  So far, I am not sure, but I think a flag in the manifest will allow a pure networking access ("Use the host network namespace").
bkor 12y ago
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 on what an application can do Edit: What I meant is: Is it possible to lower your requirements or change how VLC works/can do when it is sandboxed?
- jbk 12y ago
  > 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.
  - sp332 12y ago
    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.
    - asveikau 12y ago
      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.
      - edohyiez 12y ago
        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.
  - tormeh 12y ago
    >You really need to be able to open a file without file opener What if you had read/write access to /home/user/music and /home/user/video ? Once we start adding blanket access like this we would probably need to add a /home/user/secret folder that no application can access unless invited to a specific file by a file opener.
alexlarsson 12y ago
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
- weland 12y ago
  > 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 :)?
  - alexlarsson 12y ago
    PulseAudio can be very low latency. Here are some docs on how to set this up: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/Developer/Clients/LatencyControl/ 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.
rogerbinns 12y ago
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.
- jbk 12y ago
  And how do you share the buffers between the apps?
  - rogerbinns 12y ago
    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.
    - jbk 12y ago
      No it has not. 0-copy shared buffer don't exist yet for most video usecases.
      - rogerbinns 12y ago
        Are you saying it is completely impossible? Or that they haven't done it yet? The former would be a big problem, and the latter is just about the right apis, driver models etc.
        jbk 12y ago
        > Are you saying it is completely impossible? Nothing is impossible, this is software. But it's far far far from being ready.
agwa 12y ago
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, and I think it has more promise than trying to sandbox entire apps. Many apps have complex access requirements (much more than the game used as an example in this blog post) and trying to sandbox them will require granting so much privilege that the sandbox becomes almost meaningless. I'm currently working on converting a PDF viewer to use privilege separation. I'd love to see a media player use privilege separation too. Does VLC currently have pretty clear separation between its various components? Do you think it be much work to spin security-conscious parts like the decoders into separate processes?
- jbk 12y ago
  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 decoders. The crashes mostly happen in protocols and demuxers, but not in decoders (a contrario from what people think). 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. For audio output, it's not good either, although some platforms are better (pulseaudio+Kdbus might work).
  - chubot 12y ago
    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/ 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.
davidgerard 12y ago
>they refuse blankly, saying that my "use case is irrelevant and dangerous". Because it's not like anyone uses media players in the real world. Seriously, WHAT?
upofadown 12y ago
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.
- cplease 12y ago
  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.
  - edohyiez 12y ago
    > 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?
    - cplease 12y ago
      It depends on what you mean by "sandboxing" and "app." But basically, with a browser or mobile app, there's a limited number of functions that you may want to permit an app to access, and it's okay to isolate the rest of the app to its own little world. With desktop apps, you generally want to be able to use apply them broadly to all your user data, or you will quickly be frustrated with them. Deeper-level sandboxing of splitting the app up into bipartite high and low-security/complexity components, as with the Chrome browser, requires a lot of engineering for the particular application and can't simply be dropped in place on a given off-the-shelf Linux app. Coarser-level application-specific permissions in the form of AppArmor profiles, installing daemons as their own users with chroots etc, is already available and deployed. The technology to go further with it is already there.
zanny 12y ago
With Wayland and dbus and all the techs going into a modern Linux desktop, it is probably very doable to prompt users when a program tries to open a file with a simple "Application X wants to open file Y in location Z, let it? Yes / No / Allow for all contents of Z / Allow All Locations". That would be a misnomer, because "important" file locations like ~/.config, ~/.share, etc would always prompt user acknowledgement when a program tries to open something in those and it is not the originator program (ie, VLC can open something like ~/.config/vlc or ~/.share/vlc, but if it tried to open ~/.config/mplayer or ~/.share/mplayer you would get a prompt notification of it. > access (and unique probably) to raw devices read-only I don't think this is hard at all, device permissions are something that mostly already works. Just say "App X wants to access device Y, allow? Yes / No / Always". With good package management and distributors, you could have most of these "prompts" configured with sane defaults so you don't get spam when VLC opens files - the distro can just trust VLC in ~/Music and ~/Video all the time, and any user made directories, so just give it access everywhere except the config and share dirs, so on and so forth. When you install something it would make sense to tell users what it uses in the same way Android does upon installation, and if it tries to access something post-install you get a dialog about it (ie, VLC could say at install it uses the network, or it could ask at runtime if it tries to access the network). Why would VLC need raw audio out? Route through pulseaudio, nobody should be opening raw audio devices anymore unless you are Ardour. I think the real problem is nobody gives a shit about desktop security. I mean I run Archlinux where there isn't a single working MAC solution that does not require days of prep work. But having delved a lot into Mac and such, I have no faith in Apparmor or SELinux when PAX and Grsec is doing a much better job and nobody is using it. And they all have holes somewhere, either they don't have fine grained device permissions, or lack tunables, or don't harden the kernel enough to avoid simple exploits. Its a mess nobody is really trying to solve upstream of security implementations and distros are doing a half assed job about it across the board.
em3rgent0rdr 12y ago
for such security, you should use something like Qubes OS (https://qubes-os.org/ https://qubes-os.org/) which uses Xen to sandbox apps into different domains (VMs), and keeps the networking stack in a seperate VM, disk storage in a seperate VM, DE in a seperate VM, etc.
tracker1 12y ago
what's wrong with having a service layer that isn't sandboxed, and an application layer that is? What's stopping you from running your filesystem and network requests through a local service... you can sandbox all the rendering and other access, and tighten controls on your service interface.
deleted 12y ago
[deleted]
digi_owl 12y ago
Yeah, if this sandboxing is anything like the Storage Access Framework that Google introduced in Android 4.4, i'll pass...

alexkudryashkin 12y ago

http://i3.kym-cdn.com/photos/images/facebook/000/731/143/3e3.jpg http://i3.kym-cdn.com/photos/images/facebook/000/731/143/3e3...

_pmf_ 12y ago

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 12y ago
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 12y ago
  To be fair, this has exactly zero effect on the NSA hacking your machine, especially if the hard disk firmware is compromised.
  - tormeh 12y ago
    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 12y ago

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

grigio 12y ago
chroot existed before 11 mag 2010
- compsciphd 12y ago
  apparently you think usenix atc is unaware of chroot as well :)

grigio 12y ago

better later than never

riskable 12y ago

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 12y ago
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?

davexunit 12y ago

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

gegenschall 12y ago
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.
- davexunit 12y ago
  bind-mounting and/or symlinks are good ways to go. That way there isn't unnecessary duplication.
jblow 12y ago
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 12y ago
  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 12y ago
    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.

mempko 12y ago

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 12y ago
It's not about "not trusting the user", but about the user not having to trust the author of the application.
- tonyedgecombe 12y ago
  The result is still the same though.
  - edohyiez 12y ago
    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 12y ago
      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 12y ago
        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.

hitlin37 12y ago

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

iso8859-1 12y ago
I don't think this will help you. It sounds more like you need something like buildroot or 0install.
- hitlin37 12y ago
  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.?

ndesaulniers 12y ago

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

copsarebastards 12y ago

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

bitL 12y ago

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?

tobbyb 12y ago

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-containers/ https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-container...

timthelion 12y ago

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_applications_with_docker.html http://www.jann.cc/2014/09/06/sandboxing_proprietary_applica..., https://github.com/Kagami/kagome https://github.com/Kagami/kagome

alexlarsson 12y ago
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.

ageofwant 12y ago

Y U No Docker ?

yarrel 12y ago

The cargo-culting continues.

diltonm 12y ago

>> 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 12y ago
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 12y ago

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?

ExpiredLink 12y ago

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