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

121–130 of 136 posts

Re: First fully sandboxed Linux desktop app

#121

Post by alexlarsson »

jbk wrote: post #72
alexlarsson wrote: post #44

Earlier quoted context omitted.

> 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. Did you look into the new memfd support in the kernels? Seems like this is a pretty cool way…

> For hardware decoders, maybe using dmabuff buffers shared between multiple processes would work? This is not portable, but this is a possible solution for Linux. But this is far from being ready, which is one of my main point :)

Well, the sandboxing stuff is not ready either. We need work on all levels of the stack to make this stuff work.

Re: First fully sandboxed Linux desktop app

#122

Post by alexlarsson »

timthelion wrote: post #104

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... , https://github.com/Kagami/kagome

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.

Re: First fully sandboxed Linux desktop app

#123

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

Re: First fully sandboxed Linux desktop app

#124

Post by bkor »

jbk wrote: post #15
alexlarsson wrote: post #7

Earlier quoted context omitted.

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…

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

> I'm making sure the same does not happen on Linux, before we get kicked out of our own platform.

To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This sandboxing (together with other bits) would allow you to distribute your application eventually 80% of the various Linux distribution users. I think it'll take some time because there's a lot of things to work out (e.g. relying on Wayland, kdbus, change Pulseaudio to use kdbus, etc).

A user should have control on what an application can do, but that's something new and user might highly prefer such applications (e.g. not allowing an application to just modify ~/.bashrc and adding some evil sudo alias if it feels like it).

IMO at most you'd have some package software which shows for VLC: "unrestricted access". The intention is to offer more security where possible to the user while at the same time it's not too difficult for the developer.

Re: First fully sandboxed Linux desktop app

#125

Post by banjax »

riskable wrote: post #42
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.

Just to clarify: No one cares if a video player has low-latency audio as long as the audio latency matches the video latency. As in, it totally sucks when the words coming out of an actor's mouth don't line up with the audio. The only place where low-latency matters is real-time encoding situations. For example, video conferencing, composing music, streaming things live, etc but even in those situations "low" is a re…

Even https://code.google.com/p/android/issues/detail?id=3434

Re: First fully sandboxed Linux desktop app

#126

Post by jbk »

bkor wrote: post #124
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…

> I'm making sure the same does not happen on Linux, before we get kicked out of our own platform. To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution. This sandboxing (together with other bits) would allow you to distribute your application eventually 80% of the various Linux distribution users. I think it'll…

> To make one thing very clear: Sandboxing is partly intended to be an additional way to distribute software. Majority of the packages come from your distribution.

This is not what we understand from your GnomeOS talks and systemd "distributions are obsolete" posts.

Re: First fully sandboxed Linux desktop app

#127

Post by jbk »

MaulingMonkey wrote: post #106
jbk wrote: post #70

Earlier quoted context omitted.

> If the file chooser is powerful enough, couldn't it be? Experience from OS X and WinRT is that they aren't powerful. > I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 What about mkv linked files or .mpc lossless complements? Or cue/bin complements? What about m3u that have mp3, ogg and flac interleaved? It's not that simple.

> Experience from OS X and WinRT is that they aren't powerful. And I'm not suggesting that the current state of things is sufficient. > What about mkv linked files or .mpc lossless complements? Or cue/bin complements? > What about m3u that have mp3, ogg and flac interleaved? In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?…

> In my case? As I don't use these formats, these are signs of bad things are happening (fishing for file format specific overflows in the parser?), and it is that simple.

You don't use mkv or playlists with mixed content? You don't use subtitles?

> the ability to grant ~/music/.../.{mp3,ogg,flac} [...] If it is, your codebase is suffering from some serious bitrot... I sympathize, but whitelisting isn't the problem at that point.

Your first idea is that our codebase is bitrot? Seriously?

> which file types we want to associate with our media players. Reuse and retool those, profit?

And you know, it's been a long time we don't rely on extensions for format detection.

Sorry, but your comment is very arrogant (limit insulting), and you speak of things you don't understand.

Re: First fully sandboxed Linux desktop app

#128

Post by jbk »

rogerbinns wrote: post #85
jbk wrote: post #75

Earlier quoted context omitted.

No it has not. 0-copy shared buffer don't exist yet for most video usecases.

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.

> Are you saying it is completely impossible?

Nothing is impossible, this is software. But it's far far far from being ready.

Re: First fully sandboxed Linux desktop app

#130

Post by dbdr »

kayamon wrote: post #116
edohyiez wrote: post #59

Earlier quoted context omitted.

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…

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

Post reply on HN