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

111–120 of 136 posts

Re: First fully sandboxed Linux desktop app

#111

Post by cplease »

detaro wrote: post #99
cplease wrote: post #91

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

You don't need a different file chooser widget for that. You can use AppArmor or other MAC systems.

Re: First fully sandboxed Linux desktop app

#112

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

Re: First fully sandboxed Linux desktop app

#113

Post by edohyiez »

diltonm wrote: post #112

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

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.

Re: First fully sandboxed Linux desktop app

#114

Post by edohyiez »

cplease wrote: post #111
detaro wrote: post #99

Earlier quoted context omitted.

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.

You don't need a different file chooser widget for that. You can use AppArmor or other MAC systems.

Can you really? With the external file chooser, the app has no access to user files before a file is picked, then has access to only this one particular file, and after it is closed returns to no access again.

How would you do this with a generic MAC system without using additional software that dynamically changes the MAC policy and/or relabels files and without bothering the user?

Re: First fully sandboxed Linux desktop app

#115

Post by jgrowl »

jblow wrote: post #55
davexunit wrote: post #25

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

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

Seems like Linus agrees with you to an extent. He thinks it is sad to have to statically link libraries and create huge binaries but it is what you currently have to do to ensure things don't break.

Be aware of typical Linus swearing: https://www.youtube.com/watch?v=5PmHRSeA2c8#t=358

Re: First fully sandboxed Linux desktop app

#116

Post by kayamon »

edohyiez wrote: post #59
jblow wrote: post #55

Earlier quoted context omitted.

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

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

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.

Re: First fully sandboxed Linux desktop app

#117

Post by hitlin37 »

iso8859-1 wrote: post #98
hitlin37 wrote: post #82

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

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

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

Re: First fully sandboxed Linux desktop app

#118

Post by alexlarsson »

comex wrote: post #87
alexlarsson wrote: post #84

Earlier quoted context omitted.

Sharing a normal memory mapping is not necessarily what is required here though. What you want is to share the same GPU-side memory buffer between two processes. It may not even be mappable to cpu side memory.

If it's mapped into the CPU address space, then it can be shared. If not, then there is a copy going on and you may as well just do it in the non-sandboxed process, no?

There is no copy. You have a reference to a GPU side buffer, and you want to pass a reference to that buffer to another process, where it will continue to use the GPU to access it.

Re: First fully sandboxed Linux desktop app

#119

Post by alexlarsson »

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…

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.

Re: First fully sandboxed Linux desktop app

#120

Post by alexlarsson »

pdkl95 wrote: post #95
alexlarsson wrote: post #11

Earlier quoted context omitted.

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

Raising the latency is what you want in many cases. For instance, the current discussion is about a video player. There is no need for a video player to submit new data every 10ms, because it knows exactly what it will be playing for the next N seconds (depending on the buffer size it uses). Waking up every 10ms just causes more cpu and power use and risks missing the deadline.

Of course, there are cases where you do need lower latencies, such as games where interactive feedback cause the sound to change, or when you pause a movie. In those cases you adjust the latency (possibly temporarily in the case of the pause).

That said, PulseAudio has a different set of requirements and thus design decisions from Jack. It is not meant to be used in music production, but then again, I doubt the music producers will use some sandboxed app to do music production either. So, I don't see the problem here.

Post reply on HN