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

61–70 of 136 posts

Re: First fully sandboxed Linux desktop app

#61

Post by azernik »

mempko wrote: post #58
edohyiez wrote: post #36

Earlier quoted context omitted.

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.

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.

You think you can trust the authors of every free software package to have kept out all security flaws? That's a mighty happy world you live in.

Re: First fully sandboxed Linux desktop app

#62

Post by nhaehnle »

agwa wrote: post #12
jbk wrote: post #2

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…

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…

Keep in mind that privilege separation does not cover all possible use cases of sandboxing.

Privilege separation is an answer to the question: "I have a program whose authors I trust even though they are fallible, and the program needs to process untrusted data"

In desktop scenarios, I really want an answer to the question: "I have a program whose authors I don't trust, but I want to run it anyway"

For that, you really need full sandboxing; privilege separation is not enough.

Re: First fully sandboxed Linux desktop app

#63

Post by cplease »

edohyiez wrote: post #46
cplease wrote: post #43

Earlier quoted context omitted.

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

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

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.

Re: First fully sandboxed Linux desktop app

#64

Post by wlesieutre »

MaulingMonkey wrote: post #60
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. If the file chooser is powerful enough, couldn't it be? I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as…

Double star makes italics on whatever's in between them, but you should be able to escape them with backslashes like this * *.

Re: First fully sandboxed Linux desktop app

#65

Post by wlesieutre »

wlesieutre wrote: post #64
MaulingMonkey wrote: post #60

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. If the file chooser is powerful enough, couldn't it be? I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as…

Double star makes italics on whatever's in between them, but you should be able to escape them with backslashes like this * *.

That actually took a couple of edits with inconsistent results. Sometimes it actually prints the backslash? \* \*.

And it definitely likes having a space in between, otherwise the second slash gets styled in italics. Curious.

Re: First fully sandboxed Linux desktop app

#66

Post by vidarh »

mempko wrote: post #58
edohyiez wrote: post #36

Earlier quoted context omitted.

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.

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.

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.

Re: First fully sandboxed Linux desktop app

#67

Post by joelthelion »

mintplant wrote: post #21
_pmf_ wrote: post #9

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!

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.

Re: First fully sandboxed Linux desktop app

#68

Post by zokier »

mempko wrote: post #30

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.

Do you run everything as root? Why not, don't you trust the user?

Re: First fully sandboxed Linux desktop app

#69

Post by jbk »

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…

> Hopefully we can take this into account when we look into the details here.

This is all I'm asking, and not the usual "I don't care about your usecase, you should just use GStreamer" that we get from the Gnome/RedHat/Systemd team.

Re: First fully sandboxed Linux desktop app

#70

Post by jbk »

MaulingMonkey wrote: post #60
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. If the file chooser is powerful enough, couldn't it be? I don't use VLC playlists at all, but I could e.g. grant read-only ~/music/.../*.mp3 (edit: apparently I can't double star) access, and that'd be enough for my music playlists as far as…

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

Post reply on HN