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

91–100 of 136 posts

Re: First fully sandboxed Linux desktop app

#91

Post by cplease »

edohyiez wrote: post #79
cplease wrote: post #63

Earlier quoted context omitted.

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…

I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect. Of course it's important that the sandbox doesn't frustrate you or lead you to blindly click "A…

> I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect.

You do want LibreOffice, Gimp, VLC, and your webbrowser to be able to save and open their respective media files in your home folder, right? And you want might want them to be able to actually work together, right? Such as opening a file you downloaded in the browser. Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.

What you seem disturbed by is that one application can access configuration and state data belonging to another application. Because they are just files, belonging to the same user. Well, I suppose if such a policy made you feel better, you could always change the AppArmor profiles to only allow an application to modify its own dotfiles, dotdirectory, e.g., fooapp can't touch ~/.* except ~/.fooapp. That's not a terrible idea, although if you are so distrustful of it to begin with and still want to run it you should probably sandbox it in its own filesystem altogether. And this will break some interoperability.

Re: First fully sandboxed Linux desktop app

#92

Post by greggman »

alexlarsson wrote: post #39
jbk wrote: post #15

Earlier quoted context omitted.

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

>> 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 i…

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.

Re: First fully sandboxed Linux desktop app

#93

Post by tormeh »

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.

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

Re: First fully sandboxed Linux desktop app

#94

Post by tormeh »

joelthelion wrote: post #67
mintplant wrote: post #21

Earlier quoted context omitted.

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.

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

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.

Re: First fully sandboxed Linux desktop app

#95

Post by pdkl95 »

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

Earlier quoted context omitted.

> Is raw audio output necessary? Why does not pulseaudio work? I don't know if this applies to VLC, too, but raw audio output (or something that isn't PulseAudio) is necessary wherever low (or at least constant) latency is required. Edit: oh - now that I look at your username, I believe congratulations are in order re. the subject of this thread :)?

PulseAudio can be very low latency. Here are some docs on how to set this up: http://www.freedesktop.org/wiki/Software/PulseAudio/Document... That said, I don't think a video player needs low latencies. It can generally have pretty large buffers.

That link seems to encourage raising the latency, which suggests the needs of people like musicians are not being considered at all. Your use-cases are not the only use cases that exist.

The entire world of music production uses JACK, which got the design right well before PulseAudio even existed. It can provide synchronous operation to prevent drifting between audio tools. I include mplayer2 as one of those tools for s few things. More importantly, JACK guarantees a reliable very, very low latency audio path.

How "low latency" do I mean? Consider that in printed music, while somewhat uncommon, quite a few pieces have been written that use 128th notes. That would be anywhere from ~80ms to ~10ms note lengths, depending on the tempo. Larger latencies mean notes being heard as a different note from what was played, and I keep JACK down to about 5ms latency, and would set it lower if I could afford new hardware. Notes are not the only feature of musinc, and some headroom is needed. Any latencies higher than about 10ms-20ms I would consider broken and unusable.

(Incidentally - I cannot play GuitarHero/RockBand on most TVs either because of horrible latench. A (60Hz) video, a two frame delay is a "miss" on the harder songs. those 16.6ms latencies are nasty regardless which direction the latency is being added)

Beyond that, JACK is a great API. It makes it trivial to do a LOT of the common needs (i.e. "Just give me the audio samples..." or "just let me write new audio data and not have to worry about anything else... such as timing")

Re: First fully sandboxed Linux desktop app

#96

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

Re: First fully sandboxed Linux desktop app

#97

Post by lunixbochs »

greggman wrote: post #92
alexlarsson wrote: post #39

Earlier quoted context omitted.

>> 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 i…

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 process…

I'm pretty sure DRI doesn't do anything special to the OpenGL calls, so they just get punted into the scary binary client library from your GPU vendor.

Re: First fully sandboxed Linux desktop app

#99

Post by detaro »

cplease wrote: post #91
edohyiez wrote: post #79

Earlier quoted context omitted.

I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect. Of course it's important that the sandbox doesn't frustrate you or lead you to blindly click "A…

> I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect. You do want LibreOffice, Gimp, VLC, and your webbrowser to be able to save and open their res…

A file chooser outside the application is safer if the sandbox enforces that only selected files are opened. Of course I want the app to be able to read files I told it to open, but it shouldn't be able to access files I haven't selected.

Re: First fully sandboxed Linux desktop app

#100

Post by edohyiez »

cplease wrote: post #91
edohyiez wrote: post #79

Earlier quoted context omitted.

I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect. Of course it's important that the sandbox doesn't frustrate you or lead you to blindly click "A…

> I actually don't want all desktop apps to be able to access all my data all the time. E.g. why should LibreOffice be able to access my browsing history, or Gimp be able to read the contacts in my address book, or VLC be able to read my e-mails? I don't see the difference between desktop and mobile/web apps in this respect. You do want LibreOffice, Gimp, VLC, and your webbrowser to be able to save and open their res…

Yes, I want applications to be able to open files and to work together, but only if that's needed to achive what I want them to do. LibreOffice should be able to open (and read from and write to) any .odt-file that I want to edit. But since to do that it doesn't need to have access to my browsing history, I don't want it to have access to that. Is it weird that I want that?

> Whether the file chooser is inside your application or outside your application doesn't make it any safer, it's the fact that the application has the ability to open and read/write the files.

Yes, it does. If the file chooser is inside the application, it needs to be able to open the chosen file, i.e. an arbitrary path, at any time. If the file chooser is outside the sandbox, the application only gets the open fd and can't open files itself (open(2) would simply fail). That is a huge difference!

> What you seem disturbed by is that one application can access configuration and state data belonging to another application.

Yes, I am disturbed by that and I am certainly not alone. There simply is no reason why it should be that way, apart from backwards-compatibility. Why should I have to trust the hundreds of millions of lines of code in all the applications on my machine, if such a huge amount of trust is not necessary to achive the desired outcome?

And sure, application sandboxing can already be achived with AppArmor or SELinux (or a multitude of other systems), but it requires manual work (afaik no major distribution comes with this out of the box) and (as you correctly write) it breaks interoperability. The goal of this "Gnome app sandbox" isn't to be the first application sandbox, but to provide the possibility to enable this by default for certain applications and to keep interoperability. That last part is mostly a research project, so I don't expect this to be finished any time soon.

Post reply on HN